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NATIONAL FOREWORD 

This Indian Standard which is identical with ISO/IEC 1 8045 ; 2005 'Information technology — Security techniques 
— Methodology for IT security evaluation' issued by the International Organization 1or Standardization (ISO) 
and International Electrotechnical Commission (lEC) jointly was adopted by the Bureau of Indian Standards 
on the recommendations of the Information Systems Security Sectional Committee and approval of the 
Electronics and Information Technology Division Council. 

The text of the ISO/IEC Standard has been approved as suitable for publication as an Indian Standard without 
deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention is 
particularly drawn to the following: 

a) Wherever the words -Internationa! Standard' appear referring to this standard, they should be read 
as 'Indian Standard*. 

b) Comma (,) has been used as a decimal marker while in Indian Standards, the current practice is to 
use a point (.) as the decimal marker. 
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Indian Standard 

INFORMATION TECHNOLOGY — 

SECURITY TECHNIQUES — METHODOLOGY 

FOR IT SECURITY EVALUATION 



1 Scope 

This International Standard is a companion document to ISO/IEC 15408, Information technology — Security 
techniques — Evaluation criteria for IT security. This International Standard describes the minimum actions 
to be performed by an evaluator in order to conduct an ISO/IEC 15408 evaluation, using the criteria and 
evaluation evidence defined in ISO/IEC 15408. 

2 Normative references 

The following referenced documents are indispensable for the application of this document. For dated 
references, only the edition cited applies. For undated references, the latest edition of the referenced 
document (including any amendments) applies. 

ISO/IEC 1 5408 (all parts). Information technology — Security techniques — Evaluation criteha for IT security 

3 Terms and definitions 

For the purposes of this document, the following terms and definitions apply. 

NOTE Bold-faced type is used in the definitions to indicate terms which are themselves defined in this clause. 

3.1 
action 

evaluator action element of ISO/IEC 15408-3. These actions are either explicitly stated as evaluator actions or 
implicitly derived from developer actions (implied evaluator actions) within ISO/IEC 15408-3 assurance 
components. 

3.2 
activity 

the application of an assurance class of ISO/IEC 15408-3. 

3.3 
checl< 

to generate a verdict by a simple comparison. Evaluator expertise is not required. The statement that uses 
this verb describes what is mapped. 

3.4 

evaluation deliverable 

any resource required from the sponsor or developer by the evaluator or overseer to perform one or more 
evaluation or evaluation oversight activities. 

3.5 

evaluation evidence 

a tangible evaluation deliverable. 
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3.6 

evaluation technical report 

a report that documents the overall verdict and its justification, produced by the evaluator and submitted to 

an overseer. 

3.7 
examine 

to generate a verdict by analysis using evaluator expertise. The statement that uses this verb identifies what 
is analysed and the properties for which it is analysed. 

3.8 
interpretation 

a clarifiuation or amplification of an ISO/IEC 1 5408, ISO/IEC 1 8045 or scheme requirement. 

3.9 
methodology 

the system of principles, procedures and processes applied to IT security evaluations. 

3.10 

observation report 

a report written by the evaluator requesting a clarification or Identifying a problem during the evaluation. 

3.11 

overall verdict 

a pass or fail statement issued by an evaluator with respect to the result of an evaluation. 

3.12 

oversight verdict 

a statement issued by an overseer confirming or rejecting an overall verdict based on the results of evaluation 
oversight activities. 

3.13 
record 

to retain a written description of procedures, events, observations, insights and results in sufficient detail to 
enable the work performed during the evaluation to be reconstructed at a later time. 

3.14 

report 

to include evaluation results and supporting material in the evaluation technical report or an observation 

report. 

3.15 
scheme 

set of rules, established by an evaluation authority, defining the evaluation environment, including criteria and 
methodology required to conduct IT security evaluations. 

3.16 
sub-activity 

the application of an assurance component of ISO/IEC 15408-3. Assurance families are not explicitly 
addressed in this International Standard because evaluations are conducted on a single assurance 
component from an assurance family. 

3.17 
tracing 

a simple directional relation between two sets of entities, which shows which entities in the first set correspond 
to which entities in the second. 
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3.18 
verdict 

a pass, fail or inconclusive statement issued by an evaluator with respect to an ISO/IEC 15408 evaluator 
action element, assurance component, or class. Also see overall verdict. 

3.19 
work unit 

the most granular level of evaluation work. Each evaluation methodology action comprises one or more work 
units, which are grouped within the evaluation methodology action by ISO/IEC 15408 content and 
presentation of evidence or developer action element. The work units are presented in this International 
Standard in the same order as ISO/IEC 15408 elements from which they are derived. Work units are identified 
in the left margin by a symbol such as 4:ALCjrAT.1-2. In this symbol, the first digit (4) indicates the EAL; the 
string ALC_TAT.1 indicates ISO/IEC 15408 component (i.e. this International Standard sub-activity), and the 
final digit ( 2) indicates that this is the second work unit in the ALC_TAT.1 sub-activity. 

4 Symbols and abbreviated terms 

ETR Evaluation Technical Report 

OR Observation Report 

5 Overview 

5.1 Organisation of this International Standard 

Clause 6 defines the conventions used in this International Standard. 

Clause 7 describes general evaluation tasks with no verdicts associated with them as they do not map to 
ISO/IEC 15408 evaluator action elements. 

Clause 8 defines the evaluation of a PP. 

Clause 9 defines the evaluation of an ST. 

Clauses 10 to 13 define the minimal evaluation effort for achieving EAL1 to EAL4 evaluations and to provide 
guidance on ways and means of accomplishing the evaluation. 

Clause 14 defines the flaw remediation evaluation activities. 

Annex A covers the basic evaluation techniques used to provide technical evidence of evaluation results. 

6 Document Conventions 

6.1 Terminology 

Unlike ISO/IEC 15408, where each element maintains the last digit of its identifying symbol for all components 
within the family, this International Standard may introduce new work units when an ISO/IEC 15408 evaluator 
action element changes from sub-activity to sub-activity; as a result, the last digit of the work unit's identifying 
symbol may change although the work unit remains unchanged. For example, because an additional work unit 
labeled 4:ADV_FSP.2-7 was added at EAL4, the subsequent sequential. numbering of FSP work units is offset 
by one. Thus work unit 3:ADV_FSP.1-8 is now mirrored by work unit 4:ADV_FSP.2-9; each express the same 
requirement though their numbering no longer directly correspond. 

Any methodology-specific evaluation work required that is not derived directly from ISO/IEC 15408 
requirements is termed task or sub-task. 



IS 15671 : 2006 
ISO/IEC 18045 : 2005 

6.2 Verb usage 

All work unit and sub-task verbs are preceded by the auxiliary verb shall and by presenting both the verb and 
the shall mbold italic type face. The auxiliary verb shall is used only when the provided text is mandatory and 
therefore only within the work units and sub-tasks. The work units and sub-tasks contain mandatory activities 
that the evaluator must perform in order to assign verdicts. 

Guidance text accompanying work units and sub-tasks gives further explanation on how to apply ISO/IEC 
15408 words in an evaluation. The described method is normative, meaning that the verb usage is in 
accordance with ISO definitions for these verbs; that is: the auxiliary verb should \s used when the described 
method is strongly preferred and the auxiliary verb may is used where the described method(s) is allowed but 
no preference is indicated. {The auxiliary verb shall is used only for the text of work units.) 

The verbs check, examine, report and record are used with a precise meaning within this International 
Standard and the clause 3 should be referenced for their definitions. 

6.3 General evaluation guidance 

Material that has applicability to more than one sub-activity is collected rn one place. Guidance whose 
applicability is widespread (across activities and EALs) has been collected into Annex A. Guidance that 
pertains to multiple sub-activities within a single activity has been provided in the introduction to that activity. If 
guidance pertains to only a single sub-activity, it is presented within that sub-activity. 

6.4 Relationship between ISO/IEC 15408 and ISO/IEC 18045 structures 

There are direct relationships between ISO/IEC 15408 structure (i.e. class, family, component and element) 
and the structure of this International Standard. Figure 1 illustrates the correspondence between ISO/IEC 
1 5408 constructs of class, family and evaluator action elements and evaluation methodology activities, sub- 
activities and actions. However, several evaluation methodology work units may result from the requirements 
noted in ISO/IEC 15408 developer action and content and presentation elements. 

Common Criteria Common Evaluation Methodology 



Figure 1 - IVIapping of ISO/IEC 15408 and ISO/IEC 18045 structures 
6.5 Evaluator verdicts 

The evaluator assigns verdicts to the requirements of ISO/IEC 15408 and not to those of this Internationa! 
Standard. The most granular ISO/IEC 15408 structure to which a verdict is assigned is the evaluator action 
element (explicit or implied). A verdict is assigned to an applicable ISO/IEC 15408 evaluator action element as 
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a result of performing the corresponding evaluation methodology action and its constituent work units. Finally, 
an evaluation result is assigned, as described in ISO/IEC 15408-1. Sut>ctause 6.3. 



Evaluation Result 



Assurance Class 



Assurance Component 



Evaluator Action Element 




Evaluator Action Element 




Evaluator Action Element 
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Figure 2 - Example of the verdict assignment rule 

This International Standard recognises three mutually exclusive verdict states: 

a) Conditions for a pass verdict are defined as an evaluator completion of ISO/IEC 15408 evaluator action 
element and detennination that the requirements for the PP, ST or TOE under evaluation are met. The 
conditions for passing the element are defined as the constituent work units of the related evaluation 
methodology action; 

b) Conditions for an inconclusive verdict are defined as an evaluator incompletion of one or more work units 
of the evaluation methodology action related to ISO/IEC 15408 evaluator action element; 

c) Conditions for a fail verdict are defined as an evaluator completion of ISO/IEC 15408 evaluator action 
element and determination that the requirements for the PP, ST, or TOE under evaluation are not met. 

All verdicts are initially inconclusive and remain so until either a pass or fail verdict is assigned. 

The overall verdict is pass if and only if all the constituent verdicts are also pass. In the example illustrated in 
Figure 2, if the verdict for one evaluator action element is fail then the verdicts for the corresponding 
assurance component, assurance class, and overall verdict are also fail. 

7 General evaluation tasks 



7.1 Introduction 

All evaluations, whether of a PP or TOE (including ST), have two evaluator tasks in common; the input task 
and the output task. These two tasks, which are related to management of evaluation evidence and to report 



IS 15671 :2006 
ISO/IEC 18045 : 2005 

generation, are described in this clause. Each task has associated sub-tasks that apply to, and are normative 
for all ISO/IEC 1 5408 evaluations (evaluation of a PP or a TOE). 

Although ISO/IEC 15408 does not mandate specific requirements on these evaluation tasks, this International 
Standard does so where it is necessary. In contrast to the activities described elsewhere in this International 
Standard, these tasks have no verdicts associated with them as they do not map to ISO/IEC 15408 evaluator 
action elements; they are performed in order to comply with this International Standard. 

7.2 Evaluation input task 

7.2.1 Objectives 

The objective of this task is to ensure that the evaluator has available the correct version of the evaluation 
evidence necessary for the evaluation and that it is adequately protected. Othenwise, the technical accuracy of 
the evaluation cannot be assured, nor can it be assured that the evaluation is being conducted in a way to 
provide repeatable and reproducible results. 

7.2.2 Application notes 

The responsibility to provide all the required evaluation evidence lies with the sponsor. However, most of the 
evaluation evidence is likely to be produced and supplied by the developer, on behalf of the sponsor. Since 
the assurance requirements apply to the entire TOE, evaluation evidence pertaining to all products that are 
part of the TOE is made available to the evaluator. The scope and required content of such evaluation 
evidence is independent of the level of control that the developer has over each of the products that are part 
of the TOE. For example. If a high-level design is required, then the High-level design (ADV_HLD) 
requirements will apply to all subsystems that are part of the TSF. in addition, assurance requirements that 
call for procedures to be in place (for example, CM capabilities (ACM_CAP) and Delivery (ADO_DE! )) will 
also apply to the entire TOE (including any product from another developer). 

It is recommended that the evaluator, in conjunction with the sponsor, produce an index to required evaluation 
evidence. This index may be a set of references to the documentation. This index should contain enough 
information (e.g. a brief summary of each document, or at least an explicit title, indication of the subclauses of 
interest) to help the evaluator to find easily the required evidence. 

It is the information contained in the evaluation evidence that is required, not any particular document 
structure. Evaluation evidence for a sub-activity may be provided by separate documents, or a single 
document may satisfy several of the input requirements of a sub-activity. 

The evaluator requires stable and formally-issued versions of evaluation evidence. However, draft evaluation 
evidence may be provided during an evaluation, for example, to help an evaluator make an early, informal 
assessment, but is not used as the basis for verdicts. It may be helpful for the evaluator to see draft versions 
of particular appropriate evaluation evidence, such as: 

a) test documentation, to allow the evaluator to make an early assessment of tests and test procedures; 

b) design documents, to provide the evaluator with background for understanding the TOE design; 

c) source code x)r hardware drawings, to allow the evaluator to assess the application of the developer's 
standards. 

Draft evaluation evidence is more likely to be encountered where the evaluation of a TOE is performed 
concurrently with its development. However, it may also be encountered during the evaluation of an already- 
developed TOE where the developer has had to perform additional work to address a problem identified by 
the evaluator (e.g. to correct an error in design or implementation) or to provide evaluation evidence of 
security that is not provided in the existing documentation (e.g. in thet^se of a TOE not originally developed 
to meet the requirements of ISO/IEC 15408). 
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7.2.3 Management of evaluation evidence sub-task 

7.2.3.1 Configuration control 

The evaluator shall perform configuration control of the evaluation evidence. 

ISO/IEC 15408 implies that the evaluator is able to identify and locate each item of evaluation evidence after it 
has been received and is able to determine whether a specific version of a document is in the evaluator's 
possession. 

The evaluator shall protect the evaluation evidence from alteration or loss while it is in the evaluator's 
possession. 

7.2.3.2 Disposal 

Schemes may wish to control the disposal of evaluation evidence at the conclusion of an evaluation. The 
disposal of the evaluation evidence should be achieved by one or more of: 

a) returning the evaluation evidence; 

b) archiving the evaluation evidence; 

c) destroying the evaluation evidence. 

7.2.3.3 Confidentiality 

An evaluator may have access to sponsor and developer commercially-sensitive information (e.g. TOE design 
information, specialist tools), and may have access to nationally-sensitive information during the course of an 
evaluation. Schemes may wish to impose requirements for the evaluator to maintain the confidentiality of the 
evaluation evidence. The sponsor and evaluator may mutually agree to additional requirements as long as 
these are consistent with the scheme. 

Confidentiality requirements affect many aspects of evaluation wor)<, including the receipt, handling, storage 
and disposal of evaluation evidence. 

7.3 Evaluation output task 

7.3.1 Objectives 

The objective of this subclause is to describe the Observation Report (OR) and the Evaluation Technical 
Report (ETR). Schemes may require additional evaluator reports such as reports on individual units of work, 
or may require additional information to be contained in the OR and the ETR. This International Standard does 
not preclude the addition of information into these reports as this Internationa! Standard specifies only the 
minimum information content. 

Consistent reporting of evaluation results facilitates the achievement of the universal principle of repeatability 
and reproducibility of results. The consistency covers the type and the amount of information reported in the 
ETR and OR. ETR and OR consistency among different evaluations is the responsibility of the overseer. 

The evaluator performs the two following sub-tasks in order to achieve this International Standard 
requirements for the information content of reports: 

a) write OR sub-task (if needed in the context of the evaluation); 

b) write ETR sub-task. 
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7.3.2 Application notes 

In this version of this International Standard, the requirements for the provision of evaluator evidence to 
support re-evaluation and re-use have not been explicitly stated. The information resulting from evaluator work 
to assist in re-evaluatlon or re-use has not yet been determined by this International StandardEB under their 
current work program. Where information for re-evaluation or re-use is required by the sponsor, the scheme 
under which the evaluation is being performed should be consulted. 

7.3.3 Write OR sub-task 

ORs provide the evaluator with a mechanism to request a clarification (e.g. from the overseer on the 
application of a requirement) or to identify a problem with an aspect of the evaluation. 

In the case of a fail verdict, the evaluator shall provide an OR to reflect the evaluation result. Otherwise, the 
evaluator may use ORs as one way of expressing clarification needs. 

For each OR, the evaluator shall report the following: 

a) the identifier of the PP or TOE evaluated; 

b) the evaluation task/sub-activity during which the observation was generated; 

c) the observation; 

d) the assessment of its severity (e.g. implies a fail verdict, holds up progress on the evaluation, requires a 
resolution prior to evaluation being completed); 

e) the identification of the organisation responsible for resolving the issue; 

f) the recommended timetable for resolution; 

g) the assessment of the impact on the evaluation of failure to resolve the observation. 

The intended audience of an OR and procedures for handling the report depend on the nature of the report's 
content and on the scheme. Schemes may distinguish different types of ORs or define additional types, with 
associated differences in required information and distribution (e.g. evaluation ORs to overseers and 
sponsors). 

7.3.4 Write ETR sub-task 
7.3.4.1 Objectives 

The evaluator shall provide an ETR to present technical justification of the verdicts. 

The ETR may contain information proprietary to the developer or the sponsor. 

This International Standard defines the ETR's minimum content requirement; however, schemes may specify 
additional content and specific presentational and structural requirements. For instance, schemes may require 
that certain introductory material (e.g. disclaimers, and copyright clauses) be reported in the ETR, 

The reader of the ETR is assumed to be familiar with general concepts of information security, ISO/IEC 15408, 
this International Standard, evaluation approaches and IT. 

The ETR supports the overseer in providing the oversight verdict, but it is anticipated that it may not provide 
all of the information needed for oversight, and the documented results may not provide the evidence 
necessary for the scheme to confirm that the evaluation was done to the required standard. This aspect is 
outside the scope of this International Standard and should be met using other oversight methods. 
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7.3.4.2 ETR for a PP Evaluation 



This subclause describes the minimum content of the ETR for a PP evaluation. The contents of the ETR are 
portrayed in Figure 3; this figure may be used as a guide when constructing the structural outline of the ETR 
document. 



Evaluation Technical Report 



Introduction 



Evaluation 



Results of the evaluation 



Conclusions and recommendations 



List of evaluation evidence 



List of acronyms/Glossary of terms 



Observation reports 



Figure 3 - ETR information content for a PP evaluation 
7.3.4.2.1 Introduction 

The evaluator shall report evaluation scheme identifiers. 

Evaluation scheme identifiers (e.g. logos) are the information required to unambiguously identify the scheme 
responsible for the evaluation oversight. 

The evaluator shall report ETR configuration control identifiers. 

The ETR configuration control identifiers contain information that identifies the ETR (e.g. name, date and 
version number). 

The evaluator shall report PP configuration control identifiers. 

PP configuration control identifiers (e.g. name, date and version number) are required to identify what is being 
evaluated in order for the overseer to verify that the verdicts have been assigned correctly by the evaluator. 

The evaluator shall report the identity of the developer. 

The identity of the PP developer is required to Identify the party responsible for producing the PP. 
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The evaluator shall repoi! the Identity of the sponsor. 

The Identity of the sponsor Is required to identify the party responsible for providing evaluation evidence to the 
evaluator. 

The evaluator shall report the Identity of the evaluator. 

The identity of the evaluator is required to identify the party performing the evaluation and responsible for the 
evaluation verdicts. 

7.3.4.2.2 Evaluation 

The evaluator shall report the evaluation methods, techniques, tools and standards used. 

The evaluator references the evaluation criteria, methodology and interpretations used to evaluate Vtxe PP. 

The evaluator shall report any constraints on the evaluation, constraints on the handling of evaluation results 
and assumptions made during the evaluation that have an Impact on the evaluation results. 

The evaluator may include information in relation to legal or statutory aspects, organisation, confidentiality, etc. 

7.3.4.2.3 Results of the evaluation 

The evaluator shall report a verdict and a supporting rationale for each assurance component that constitutes 
an APE activity, as a result of performing the corresponding evaluation methodology action and its constituent 
work units. 

The rationale justifies the verdict using ISO/IEC 15408, this International Standard, any interpretations and the 
evaluation evidence examined and shows how the evaluation evidence does or does not meet each aspect of 
the criteria. It contains a description of the work performed, the method used, and any derivation of results. 
The rationale may provide detail to the level of a evaluation methodology work unit. 

7.3.4.2.4 Conclusions and recommendations 

The evaluator shall report the conclusions of the evaluation, in particular the overall verdict as defined in 
ISO/IEC 15408-1 Clause 6.3, and determined by application of the verdict assignment desaibed in 6.5. 

The evaluator provides recommendations that may be useful for the overseer. These recommendations may 
include shortcomings of the PP discovered during the evaluation or mention of features which are particularly 
useful. 

7.3.4.2.5 List of evaluation evidence 

The evaluator shall report for each item of evaluation evidence the following information: 

• the issuing body (e.g. the developer, the sponsor); 

• the title; 

• the unique reference (e.g. issue date and version number). 
7 J.4.2.6 List of acronyms/Glossary of temis 

The evaluator shall report any acronyms or abbreviations used in the ETR. 

Terms already defined by ISO/IEC 15408 or by this International Standard need not be repeated in the ETR. 
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7.3.4.2.7 Observation reports 

The evaluator shall report a complete list that uniquely identifies the ORs raised during the evaluation and 
their status. 

For each OR, the list should contain its identifier as well as its title or a brief summary of its content. 

7.3.4.3 ETR for a TOE Evaluation 

This subclause describes the minimum content of the ETR for a TOE evaluation. The contents of the ETR are 
portrayed in Figure 4; this figure may be used as a guide when constructing the structural outline of the ETR 
document. 



Evaluation Technical Report 



Introduction 



Architectural description of the TOE 



Evaluation 



Results of the evaluation 



Conclusions and recommendations 



List of evaluation evidence 



List of acronyms/Glossary of terms 



Observation reports 



Figure 4 - ETR information content for a TOE evaluation 
7.3.4.3.1 Introduction 

The evaluator shall report evaluation scheme identifiers. 

Evaluation scheme identifiers (e.g. logos) are the information required to unambiguously identify the scheme 
responsible for the evaluation oversight. 

The evaluator shall report ETR configuration control identifiers. 

The ETR configuration control identifiers contain information that identifies the ETR (e.g. name, date and 
version number). 
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The evaluator shall report ST and TOE configuration control identifiers. 

ST and TOE configuration control identifiers identify what is being evaluated in order for the overseer to verify 
that the verdicts have been assigned correctly by the evaluator. 

if the ST claims that the TOE conforms with the requirements of one or more PPs, the ETR shall report the 
reference of the corresponding PPs. 

The PPs reference contains information that uniquely identifies the PPs (e.g. title, date, and version number). 

The evaluator shall report the identity of the developer. 

The identity of the TOE developer is required to identify the party responsible for producing the TOE. 

The evaluator shall report the identity of the sponsor. 

The identity of the sponsor is required to identify the party responsible for providing evaluation evidence to the 
evaluator. 

The evaluator shall report the identity of the evaluator. 

The identity of the evaluator is required to identify the party performing the evaluation and responsible for the 
evaluation verdicts. 

7.3.4.3.2 Architectural description of the TOE 

The evaluator shall report a high level description of the TOE and its major components based on the 
evaluation evidence described in iSO/lEC 15408 assurance family entitled "High-level design (ADV_HLD)", 
where applicable. 

The intent of this subclause is to characterise the degree of architectural separation of the major components. 
If there is no High-level design (ADV_HLD) requirement in the ST, this is not applicable and is considered to 
be satisfied. 

7.3.4.3.3 Evaluation 

The evaluator shall report the evaluation methods, techniques, tools and standards used. 

The evaluator may reference the evaluation criteria, methodology and interpretations used to evaluate the 
TOE or the devices used to perform the tests. 

The evaluator shall report any constraints on the evaluation, constraints on the distribution of evaluation 
results and assumptions made during the evaluation that have an impact on the evaluation results. 

The evaluator may include information in relation to legal or statutory aspects, organisation, confidentiality, etc. 

7.3.4.3.4 Results of the evaluation 

For each activity on which the TOE is evaluated, the evaluator shall report: 

• the title of the activity considered; 

• a verdict and a supporting rationale for each assurance component that constitutes this activity, as a 
result of performing the corresponding evaluation methodology action and its constituent work units. 

The rationale justifies the verdict using iSO/lEC 15408, this International Standard, any interpretations and the 
evaluation evidence examined and shows how the evaluation evidence does or does not meet each aspect of 
the criteria. It contains a description of the work performed, the method used, and any derivation of results. 
The rationale may provide detail to the level of a evaluation methodology work unit. 
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The evaluator shall report all information specifically required by a work unit. 



For the AVA and ATE activities, work units that identify information to be reported in the ETR have been 
defined. 

7.3.4.3.5 Conclusions and recommendations 

The evaluator shall report the conclusions of the evaluation, which will relate to whether the TOE has satisfied 
its associated ST, in particular the overall verdict as defined in ISO/IEC 15408-1 Clause 6.3, and determined 
by application of the verdict assignment described in 6.5. 

The evaluator provides recommendations that may be useful for the overseer. These recommendations may 
include shortcomings of the IT product discovered during the evaluation or mention of features which are 
particularly useful. 

7.3.4.3.6 List of evaluation evidence 

The evaluator shall report for each Item of evaluation evidence the following information: 

• the issuing body (e.g. the developer, the sponsor); 

• the title; 

• the unique reference (e.g. issue date and version number). 

7.3.4.3.7 List of acronyms/Glossary of terms 

The evaluator shall report any acronyms or abbreviations used in the ETR. 

Terms already defined by ISO/IEC 15408 or by this International Standard need not be repeated in the ETR. 

7.3.4.3.8 Observation reports 

The evaluator shall report a complete list that uniquely identifies the ORs raised during the evaluation and 
their status. 

For each OR, the list should contain its identifier as well as its title or a brief summary of its content. 

7.3.5 Evaluation subractivities 

Figure 5 provides an overview of the work to be performed for an evaluation. 



13 



IS 15671 : 2006 
ISO/IEC 18045 : 2005 




Evaluation 
Input 
Task 



r) 



Evatuaiion sub-activities 



\ J 





Evaluation 
Outputs 



Figure 5 - Generic evaluation modei 

The evaluation evidence may vary depending upon the type of evaluation (PP evaluations require meVely the 
PP, while TOE evaluations require TOE-specific evidence). Evaluation outputs result in an ETR and possibly 
ORs. The evaluation sub-activities vary and, in the case of TOE evaluations, depend upon the assurance 
requirements in ISO/IEC 15408-3. 

Each of the Clauses 8 through 13 is organised similarly based on the evaluation work required for an 
evaluation. Clause 8 addresses the work necessary for reaching an evaluation result on a PP. Clause 9 
addresses the work necessary on an ST, although there is no separate evaluation result for this work. Clauses 
10 through 13 address the work necessary for reaching an evaluation result on EAL1 through EAL4 (in 
combination with the ST). Each of these clauses is meant to stand alone and hence may contain some 
repetition of text that rs included in other clauses. 

8 Protection Profile evaluation 

8.1 Introduction 

This clause describes the evaluation of a PP. The requirements and methodology for PP evaluation are 
identical for each PP evaluation, regardless of the EAL (or other set of assurance criteria) that is claimed in 
the PP. While further clauses in this International Standard are targeted at performing evaluations at specific 
EALs, this clause is applicable to any PP that is evaluated. 

The evaluation methodology in this clause is based on the requirements of the PP as specified in ISO/IEC 
1 5408-1 especially Annex A, and ISO/IEC 1 5408-3 class APE. 

8.2 PP evaluation relationships 

The activities to conduct a complete PP evaluation cover the following: 

a) evaluation input task (Clause 7); 

b) PP evaluation activity, comprising the following sub-activities: 

1) evaluation of the TOE description (Subclause 8.3.1); 

2) evaluation of the security environment (Subclause S.3.2); 

3) evaluation of the PP introduction (Subclause 8.3.3); 
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4) evaluation of the security objectives (Subclause 8.3.4); 

5) evaluation of tlie IT security requirements (Subclause 8.3.5); 

6) evaluation of the^xplicitly stated IT security requirements (Subclause 8.3.6); 

c) evaluation output task (Clause 7). 

The evaluation input and evaluation output tasks are described in Clause 7. The evaluation activities are 
derived from the APE assurance requirements contained in ISO/IEC 15408-3. 

The sub-activities comprising a PP evaluation are described in this clause. Although the sub-activities can, in 
general, be started more or less coincidentally, some dependencies between sub-activities have to be 
considered by the evaluator. For guidance on dependencies see A.4, Dependencies. 

The evaluation of the explicitly stated IT security requirements sub-activity applies only if secuiity 
requirements not taken from ISO/IEC 15408-2 or ISO/IEC 15408-3 are included in the IT security 
requirements statement 

8.3 Protection Profile evaluation activity 
8.3.1 Evaluation of TOE description (APE_DES.1) 

8.3.1.1 Objectives 

The objective of this sub-activity is to determine whether the TOE description contains relevant information to 
aid the understanding of the purpose of the TOE and its functionality, and to determine whether the 
description is complete and consistent. 

8.3.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the PP. 

8.3.1.3 Action APE_DES.1 .1 E 

8.3.1.3.1 Work unit APE_DES.1-1 

ISO/IEC 15408-3 APE_DES.1.1C: The TOE description shall describe the product type and the general IT 
features of the TOE. 

The evaluator shall examine the TOE description to determine that it describes the product or system type of 
the TOE. 

The evaluator determines that the TOE description is sufficient to give the reader a general understanding of 
the intended usage of the product or system, thus providing a context for the evaluation. Some examples of 
product or system types are: firewall, smartcard, crypto-modem, web server, intranet. 

There are situations where it is clear that some functionality is expected of the TOE because of its product or 
system type. If this functionality is absent, the evaluator determines whether the TOE description adequately 
discusses this absence. An example of this is a firewatl-type TOE, whose TOE description states that it cannot 
be connected to networks. 

8.3.1.3.2 WorkunitAPE_DES.1-2 

The evaluator shall examine the TOE description to determine that it describes the IT features of the TOE in 
general terms. 
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The evaluator determines that the TOE description discusses the IT, and in particular the security features 
offered by the TOE at a level of detail that is sufficient to give the reader a general understanding of those 

features. 

8.3.1 .4 Action APE_DES.1 .2E 

8.3.1 .4.1 Work unit APE_DES.1 -3 

The evaluator shall examine the PP to determine that the TOE description is coherent. 

The statement of the TOE description is coherent if the text and structure of the statement are understandable 
by its target audience (i.e. developers, evaluators, and consumers). 

8.3.1.4.2 WorkunitAPE_DES.1-4 

The evaluator shall examine the PP to determine that the TOE description is internally consistent. 

The evaluator is reminded that this subclause of the PP is only intended to define the general intent of the 

TOE. 

For guidance on consistency analysis see A.3, Consistency analysis. 

8.3.1.5 Action APE_DES.1.3E 

8.3.1 .5.1 Work unit APE_DES.1 -5 

The evaluator shall examine the PP to determine that the TOE description is consistent with the other parts of 
the PP. 

The evaluator determinres in particular that the TOE description does not describe threats, security features or 
configurations of the TOE that are not considered elsewhere in the PP. 

For guidance on consistency analysis see A.3, Consistency analysis. 

8.3.2 Evaluation of Security environment (APE.ENV.I) 

8.3.2.1 Objectives 

The objective of this sub-activity is to determine whether the statement of TOE security environment in the PP 
provides a clear and consistent definition of the security problem that the TOE and its environment is intended 
to address. 

8.3.2.2 Input 

The evaluation evidence for this sub-activity is: 
a) the PP. 

8.3.2.3 Action APE_ENV.1 .IE 

8.3.2.3.1 Work unit APE_ENV.1-1 

ISO/IEC 15408-3 APE_ENV.1.1C: The statement of TOE security environment shall identify and explain any 
assumptions about the intended usage of the TOE and the environment of use of the TOE. 

The evaluator shall examine the statement of TOE security environment to determine that it identifies and 
explains any assumptions. 
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The assumptions can be partitioned into assumptions about the intended usage of the TOE, and assumptions 
about the environment of use of the TOE. 

The evaluator determines that the assumptions about the intended usage of the TOE address aspects such 
as the intended application of the TOE, the potential value of the assets requiring protection by the TOE, and 
possible limitations of use of the TOE. 

The evaluator determines that each assumption about the intended usage of the TOE is explained in sufflcient 
detail to enable consumers to determine that their intended usage matches the assumption. If the 
assumptions are not clearly understood, the end result may be that consumers will use the TOE in an 
environment for which it is not intended. 

The evaluator determines that the assumptions about the environment of use of the TOE cover the physical, 
personnel, and connectivity aspects of the environment: 

a) Physical aspects include any assumptions that need to be made about the physical location of the TOE or 
attached peripheral devices in order for the TOE to function in a secure way. Some examples; 

• it is assumed that administrator consoles are in an area restricted to only administrator personnel; 

• it is assumed that alt file storage for the TOE is done on the worl<station that the TOE runs on. 

b) Personnel aspects include any assumptions that need to be made about users and administrators of the 
TOE, or other individuals (including potential threat agents) within the environment of the TOE in order for 
the TOE to function in a secure way. Some examples: 

• it is assumed that users have particular sitills or expertise; 

• it is assumed that users have a certain minimum clearance; 

• it is assumed that administrators will update the anti-virus database monthly. 

c) Connectivity aspects include any assumptions that need to be made regarding connections between the 
TOE and other IT systems or products (hardware, software, firmware or a combination thereoO that are 
external to the TOE in order for the TOE to function in a secure way. Some examples: 

• it is assumed that at least 100MB of external disk space is available to store logging files generated by 
a TOE; 

• the TOE is assumed to be the only non-operating system application being executed at a particular 
workstation; 

• the floppy drive of the TOE is assumed to be disabled; 

• it is assumed that the TOE will not be connected to an untrusted network. 

The evaluator determines that each assumption about the environment of use of the TOE is explained in 
sufficient detail to enable consumers to determine that their intended environment matches the environmental 
assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an 
environment in which it will not function in a secure manner. 

8.3.2.3.2 WorkunitAPE.ENV.1-2 

ISO/IEC 15408-3 APE_ENV.1.2C: The statement of TOE security environment shall identify and explain any 
known or presumed threats to the assets against which protection will be required, either by the TOE or by its 
environment. 

The evaluator shall examine the statement of TOE security environment to determine that it identifies and 
explains any threats. 
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If the security objectives for the TOE and its environment are derived from assumptions and organisational 
security policies only, the statement of threats need not be present in the PP. In this case, this work unit is not 
applicable and therefore considered to be satisfied. 

The evaluator determines that all identified threats are clearly explained in terms of an identified threat agent, 
the attack, and the asset that is the subject of the attack. 

The evaluator also determines that threat agents are characterised by addressing expertise, resources, and 
motivation and that a ttacks are characterised by attack methods, any vulnerabilities exploited, and 
opportunity. 

8.3.2.3.3 WorkunitAPE_ENV.1.3 

ISO/IEC 15408-3 APE_ENV.1.3C: The statement of TOE security environment sttall identify and explain any 
organisational secuhty policies with whicti the TOE must comply. 

The evaluator shall examine the statement of TOE security environment to detemr^ine that it identifies and 
explains any organisational security policies. 

If the security objectives for the TOE and its environment are derived from assumptions and threats only, 
organisational security policies need not be present in the PP. In this case, this work unit is not applicable and 
therefore considered to be satisfied. 

The evaluator determines that organisational security policy statements are made in terms of rules, practices 
or guidelines that must be followed by the TOE or its environment, as laid down by the organisation controlling 
the environment in which the TOE is to be used. An example organisational security policy is a requirement 
for password generation and encryption to conform to a standard stipulated by a national government. 

The evaluator determines that each organisational security policy is explained and/or interpreted in sufficient 
detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit 
tracing security objectives to them. 

8.3.2.4 Action APE_ENV.1.2E 

8.3.2.4.1 Work unit APE_ENV.1-4 

The evaluator shall examine the statement of TOE security environment to determine that it is coherent. 

The statement of the TOE security environment is coherent if the text and structure of the statement are 
understandable by its target audience (i.e. evaluators and consumers). 

8.3.2.4.2 Work unit APE_ENV.1.5 

The evaluator shall examine the statement of TOE security environment to determine that it is internally 

consistent. 

Examples of internally inconsistent statements jof TOE security environment are: 

a) a statement of TOE security environment that contains a threat where the attack method is not within the 
capability of its threat agent; 

b) a statement of TOE security environment that contains an organisational security policy The TOE shall 
not be connected to the Internet" and a threat where the threat agent is an intruder from the Internet. 

For guidance on consistency analysis see A.3, Consistency analysis. 
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8.3.3 Evaluation of PP introduction (APEJNT.I ) 

8.3.3.1 Objectives 

The objective of this sub-activity is to determine whether the PP introduction is complete and consistent with 
all parts of the PP and whether it correctly identifies the PP. 

8.3.3.2 Input 

The evaluation evidence for this sub-activity is: 
a) the PP. 

8.3.3.3 Action APEJNT.I. 1E 

8.3.3.3.1 Work unit APEJNT.I -1 

ISO/IEC 15408-3 APEJNT.I. 1C: The PP introduction stiall contain a PP identification that provides the 
labelling and descriptive information necessary to identify, catalogue, register, and cross reference the PP. 

The evaluator shall check that the PP introduction provides PP identification information necessary to identify, 
catalogue, register and cross reference the PP. 

The evaluator determines that the PP identification information includes: 

a) information necessary to control and uniquely identify the PP (e.g. title of the PP, version number, 
publication date, authors, sponsoring organisation); 

b) indication of the version of ISO/IEC 15408 used to develop the PP; 

c) registration information, if the PP has been registered before evaluation; 

d) cross references, if the PP is compared to other PP(s); 

e) additional information, as required by the scheme. 

8.3.3.3.2 Work unit APEJNT.I -2 

ISO/IEC 15408-3 APE_INT.1.2C: The PP introduction shall contain a PP overview which summarises the PP 
in narrative form. 

The evaluator shall check that the PP introduction provides a PP overview in narrative form. 

The PP overview is intended to provide a brief summary of the content of the PP (a more detailed description 
is provided in the TOE description) that is sufficiently detailed to enable a potential user of the PP to determine 
whether the PP is of interest. 

8.3.3.4 Action APEJNT.I. 2E 

8.3.3.4.1 Work unit APEJNT.I -3 

The evaluator shall examine the PP introduction to determine that it is coherent. 

The PP introduction is coherent if the text and structure of the statement are understandable by its target 
audience (i.e. developers, evaluators and consumers). 

8.3.3.4.2 Work unit APEJNT.I -4 

The evaluator shall examine the PP introduction to determine that it is internally consistent. 
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The internal consistency analysis will naturally focus on the PP overview that provides a summary of the 
content of the PP. 

For guidance on consistency analysis see A.3, Consistency analysis. 

8.3.3.5 Action APEJNT.1.3E 

8.3,3.5.1 Work unit APEJNT.1-5 

The evaluator shall examine the PP to determine that the PP introduction is consistent with the other parts of 
the PP. 

The evaluator determines that the PP overview provides an accurate summary of the TOE. In particular, the 
evaluator determines that the PP overview is consistent with the TOE description, and that it does not state or 
imply the presence of security features that are not in the scope of evaluation. 

The evaluator also determines that ISO/IEC 15408 conformance claim is consistent with the rest of the PP. 

For guidance on consistency analysts see A.3, Consistency analysis. 

8.3.4 Evaluation of Security xibjectives (APE_0BJ.1) 

8.3.4.1 Objectives 

The objective of this sub-activity is to determine whether the security objectives are described completely and 
consistently, and to determine whether the security objectives counter the identified threats, achieve the 
identified organisational security policies and are consistent with the stated assumptions. 

8.3.4.2 Input 

The evaluation evidence for this sub-activity is: 
a) the PP. 

8.3.4.3 Action APE_0BJ.1.1E 

8.3.4.3.1 Worl<unitAPE_OBJ.1-1 

ISO/IEC 15408-3 APE_0BJ.1.1C: The statement of security objectives sliall define ttie security objectives for 
the TOE and its environment 

The evaluator shall check that the statement of security objectives defines the security objectives for the TOE 
and its environment. 

The evaluator determines that for each security objective it is clearly specified whether it is intended to apply 
to the TOE, to the environment, or both. 

8.3.4.3.2 WorkunitAPE_OBJ.1-2 

ISO/IEC 15408-3 APE_0BJ.1.2C: The security objectives for the TOE shall be traced back to aspects of the 
identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE. 

The evaluator shall examine the security objectives rationale to determine that all security objectives for the 
TOE are traced back to aspects of the identified threats to be countered and/or aspects of the organisational 
security policies to be met by the TOE. 

The evaluator determines that each security objective for the TOE is traced back to at least one threat or 
organisational security policy. 
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Failure to trace implies that either the security objectives rationale is incomplete, the threats or organisational 
security policy statements are incomplete, or the security objective for the TOE has no useful purpose. 

A threat may therefore be addressed entirely by one or more objectives for the environment. An extreme case 
would be where there are no security objectives for the TOE. Whilst this remains a valid use of the PP/ST 
construct, a TOE for which all threats and OSPs are addressed by the environment would be of questionable 
utility, as for such a TOE there would be no security functional requirements for the TOE. 
CertificationA/alidation of such a TOE is a scheme issue. 

8.3.4.3.3 Work unit APE_OBJ.1-3 

ISO/IEC 15408-3 APE_0BJ.1 .3C: The security objectives for ttie environment stiall be traced back to aspects 
of identified threats not completely countered by the TOE and/or organisational security policies or 
assumptions not completely met by the TOE, 

The evaluator shall examine the security objectives rationale to determine that the security objectives for the 
environment are traced back to aspects of the identified threats to be countered by the TOE's environnnent 
and/or aspects of the organisational security policies to be met by the TOE's environment and/or assumptions 
to be met in the TOE's environment. 

The evafuator determines that each security objective for the environment is traced back to at least one 
assumption, threat or organisational security policy. 

Failure to trace implies that either the security objectives rationale is incomplete, the threats, assumptions or 
organisational security policy statements are incomplete, or the security objective for the environment has no 
useful purpose. 

8.3.4.3.4 Work unit APE_0BJ.1-4 

ISO/IEC 15408-3 APE_0BJ.1 .4C: The security objectives rationale shall demonstrate that the stated security 
objectives are suitable to counter the identified threats to security. 

The evaluator shall examine the security objectives rationale to determine that for each threat it contains an 
appropriate justification that the security objectives are suitable to counter that threat. 

If no security objectives trace back to the threat, this work unit fails. 

The evaluator determines that the justification for a threat demonstrates that if all security objectives that trace 
back to the threat are achieved, the threat is removed, the threat is diminished to an acceptable level, or the 
effects of the threat are sufficiently mitigated. 

The evaluator also determines that each security objective that traces back to a threat, when achieved, 
actually contributes to the removal, diminishing or mitigation of that threat. 

Examples of removing a threat are: 

• removing the ability to use an attack method from an agent; 

• removing the motivation of a threat agent by deterrence; 

• removing the threat agent (e.g. removing machines from a network that frequently crash that network). 
Examples of diminishing a threat are: 

• restricting the threat agent in attack methods; 

• restricting the threat agents in opportunity; 

• reducing the likelihood of a launched attack being successful; 

• requiring greater expertise or greater resources from the threat agent. 
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Examples of mitigating the effects of a threat are: 

• making frequent back-ups of the asset; 

• having spare copies of a TOE; 

• frequent changing of keys used in a communication session, so that the effects of breaking one key are 
relatively minor. 

Note that the tracings from security objectives to threats provided In the security objectives rationale may be a 
part of a justification, but do not constitute a justification by themselves. Even in the case that a security 
objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a 
justification is required, but this justification could be quite minimal in this case. 

8.3.4.3.5 WorkunitAPE_OBJ.1-5 

ISO/IEC 15408-3 APE_0BJ.1.5C: The security objectives rationale shall demonstrate that the stated security 
objectives are suitable to cover all of the identified organisational security policies and assumptions. 

The evaluator shall examine the security objectives rationale to determine that for each organisational security 
policy it contains an appropriate justification that the security objectives are suitable to cover that 
organisationaJ security policy. 

If no security objectives trace back to the organisational security policy, this work unit fails. 

The evaluator determines that the justification for an organisational security policy demonstrates ♦hat if all 
security objectives that trace back to that organisational security policy are achieved, the organisational 
security policy is implemented. 

The evaluator also detennines that each security objective that traces back to an organisational security policy, 
when achieved, actually contributes to the implementation of the organisational security policy. 

Note that the tracings from security objectives to organisational security policies provided in the security 
objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in 
the case that a security objective is merely a statement reflecting the intent to implement a particular 
organisational security policy, a justification is required, but this justification could be quite minimal in this case. 

8.3.4.3.6 Work unit APE_0BJ.1-6 

The evaluator shall examine the security objectives rationale to determine that for each assumption it contains 
an appropriate justification that the security objectives for the environment are suitable to cover that 
assumption. 

If no security objectives for the environment trace back to the assumption, this work unit fails. 

An assumption is either an assumption about the intended usage of the TOE, or an assumption about the 
environment of use of the TOE. 

The evaluator determines that the justification for an assumption about the intended usage of the TOE 
demonstrates that if alt security objectives for the environment that trace back to that assumption are achieved, 
the intended usage is supported. 

The evaluator also determines that each security objective for the environment that traces back to an 
assumption about tbe intended usage of the TOE, when achieved, actually contributes to the support of the 
intended usage. 
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The evaluator determines that the justification for an assumption about the environment of use of the TOE 
demonstrates that if ail security objectives for the environment that trace back to that assumption are achieved, 
the environment is consistent with the assumption. 

The evaluator also determines that each security objective for the environment that traces back to an 
assumption about the environment of use of the TOE, when achieved, actually contributes to the environment 
achieving consistency with the assumption. 

Note that the tracings from security objectives for the environment to assumptions provided in the security 
objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in 
the case that a security objective of the environment is merely a restatement of an assumption, a justification 
is required, but this justification could be quite minimal in this case. 

8.3.4.4 Action APE_0BJ.1.2E 

8.3.4.4.1 WorkunitAPE_OBJ.1-7 

The evaluator shall examine the statement of security objectives to determine that it is coherent. 

The statement of security objectives is coherent if the text and structure of the statement are understandable 
by its target audience (i.e. evaluators and consumers). 

8.3.4.4.2 Work unit APE„0BJ.1-8 

The evaluator shall examine the statement of security objectives to determine that it is complete. 

The statement of security objectives is complete if the security objectives are sufficient to counter all identified 
threats, and cover all identified organisational security policies and assumptions. This work unit may be 
performed in conjunction with the APE_0BJ.1-4, APE_0BJ.1-5 and APE_0BJ.1-6 work units. 

8.3.4.4.3 Work unit APE_0BJ.1 -9 

The evaluator shall examine the statement of security objectives to determine that it is internally consistent. 

The statement of security objectives is internally consistent if the security objectives do not contradict each 
other. An example of such a contradiction could be two security objectives as "a user's identity shall never be 
released", and "a user's identity shall be available to the other users". 

For guidance on consistency analysis see A.3, Consistency analysis. 

8.3.5 Evaluation of IT security requirements (APE_REQ.1) 

8.3.5.1 Objectives 

The objective of this sub-activity is to determine whether the TOE security requirements (both the TOE 
security functional requirements and the TOE security assurance requirements) and the security requirements 
for the IT environment are described completely and consistently, and that they provide an adequate basis for 
development of a TOE that will achieve its security objectives. 

8.3.5.2 input 

The evaluation evidence for this sub-activity is: 
a) the PP. 
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8.3.5.3 Action APE_REQ.1. IE 

8.3.5.3.1 Work unit APE_REQ.1-1 

ISO/IEC 15408-3 APE_REQ.1.1C: The statement of TOE security functional requirements shall identify the 
TOE security functional requirements drawn from ISO/IEC 15408-2 functional requirements components. 

The evaluator shall check the statement of TOE security functional requirements to determine that it identifies 
the TOE security functional requirements drawn from ISO/IEC 15408-2 functional requirements components. 

The evaluator determines that all TOE security functional requirements components drawn from ISO/IEC 
15408-2 are identified, either by reference to an individual component in ISO/IEC 15408-2, or by reproduction 

in the PP. 

8.3.5.3.2 Work unit APE_REQ.1-2 

The evaluator shall check that each reference to a TOE security functional requirement component is correct. 

The evaluator determines for each reference to a ISO/IEC 15408-2 TOE security functional requirement 
component whether the referenced component exists in ISO/IEC 1 5408-2. 

8.3.5.3.3 WorkunitAPE_REQ.1-3 

The evaluator shall check that each TOE security functional requirement component that was drawn from 
ISO/IEC 15408-2 that was reproduced in the PP, is correctly reproduced. 

The evaluator determines that the requirements are correctly reproduced in the statement of TOE security 
functional requirements without examination for permitted operations. The examination for con-ectness of 
component operations will be performed in the APE_REQ.1-1 1 work unit, 

8.3.5.3.4 WorkunitAPE„REQ.1-4 

ISO/IEC 15408-3 APE_REQ.1 .2C: The statement of TOE security assurance requirements shall identify the 
TOE security assurance requirements drawn from ISOAEC 15408-3 assurance requirements components. 

The evaluator shall check the statement of TOE security assurance requirements to determine that it identifies 
the TOE security assurance requirements drawn from ISO/IEC 15408-3 assurance requirements components. 

The evaluator determines that all TOE security assurance requirements components drawn from ISO/IEC 
16408-3 are identified, either by reference to an EAL, or by reference to an individual component in ISO/IEC 
1 5408-3, or by reproduction in the PP. 

8.3.5.3.5 WorkunitAPE_REQ.1-5 

The evaluator shall check that each reference to a TOE security assurance requirement component is correct. 

The evaluator determines for each reference to a ISO/IEC 15408-3 TOE security assurance requirement 
component whether the referenced component exists in ISO/IEC 15408-3. 

8.3.5.3.6 Work unit APE_REQ.1 -6 

The evaluator shall check that each TOE security assurance requirement component that was drawn from 
ISO/IEC 15408-3 that was reproduced in the PP, is correctly reproduced. 

The evaluator determines that the requirements are correctly reproduced in the statement of TOE security 
assurance requirements without examination for permitted operations. The examination for correctness of 
component operations will be performed in the APE_REQ.1-1 1 work unit. 
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^.3.5.3.7 Work unit APE REQ.1-7 



ISO/IEC 15408-3 APE_REQ.1.3C: The statement of TOE security assurance requirements should include an 
Evaluation Assurance Level (EAL) as defined in ISO/IEC 15408-3. 

The evaluator shall examine the statement of TOE security assurance requirements to determine that either it 
includes an EAL as defined in ISO/IEC 15408-3 or appropriately justifies that it does not include an EAL. 

If no EAL is included, the evaluator determines that the justification addresses why the statement of TOE 
assurance requirements contains no EAL. This justification may address the reason why it was Impossible, 
undesirable or inappropriate to include an EAL, or it may address why it was impossible, undesirable or 
inappropriate to include particular components of the families that constitute EAL1 (CM capabilities 
{ACM_CAP), Installation, generation and start-up (ADOJGS), Functional specification {ADV_FSP), 
Representation correspondence (ADV_RCR), Administrator guidance (AGD_ADM), User guidance 
(AGD_USR), and Independent testing (ATEJND)). 

8.3.5.3.8 WorkunitAPE_REQ.1-8 

iSO/lEC 15408-3 APE_REQ.1.4C: The evidence shall justify that the statement of TOE security assurance 
requirements is appropriate. 

The evaluator shall examine the security requirements rationale to determine that it sufficiently justifies that 
the statement of TOE security assurance requirements is appropriate. 

If the assurance requirements contain an EAL, the justification is allowed to address the choice of that EAL as 
a whole, rather than addressing all individual components of that EAL. If the assurance requirements contain 
augmented components to that EAL, the evaluator determines that each augmentation is individually justified. 
If the assurance requirements contain explicitly stated assurance requirements, the evaluator detemiines that 
the use of each explicitly stated assurance requirement is individually justified. 

The evaluator determines that the security requirements rationale sufficiently justifies that the assurance 
requirements are sufficient given the statement of security environment and security objectives. For example, 
if defence against knowledgeable attackers is required, then it would be inappropriate to specify AVA_VI_A.1 
Developer vulnerability analysis which is unlikely to detect other than obvious security weaknesses. 

The justification may also include reasons such as: 

a) specific requirements imposed by the scheme, national government, or other organisations; 

b) assurance requirements that were dependencies from TOE security functional requirement; 

c) assurance requirements of systems and/or products that are to be used in conjunction with a TOE; 

d) consumer requirements. 

An overview of the intent and goals of each EAL is provided in ISO/IEC 1 5408-3 subclause 10.2. 

The evaluator is reminded that determining whether the assurance requirements are appropriate may be 
subjective and that the analysis of sufficiency of the justification should therefore not be overly rigorous. 

If the assurance requirements do not contain an EAL, this work unit may be performed in conjunction with the 
APE_REQ.1-7 work unit. 

8.3.5.3.9 WorkunitAPE_REQ.1-9 

ISO/IEC 15408-3 APE_REQ.1.5C: The PP shall, if appropriate, identify any security requirements for the IT 
environment 

The evaluator shall check that security requirements for the IT environment are identified, if appropriate. 
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If the PP does not contain security requirements for the IT environment, this worl< unit is not applicable and 
therefore considered to be satisfied. 

The evaluator determines that any dependencies of the TOE on other IT in its environment to provide any 
security functionality in order for the TOE to achieve its security objectives are clearly identified in the PP as 
security requirements for the IT environment. 

An example of a security requirement for the IT^nvironment is a firewall that relies on an underlying operating 
system to provide authentication of administrators and permanent storage of audit data. In this case, the 
security requirements for the IT environment would contain components from the FAD: Security audit and FIA: 
Identification and authentication classes. 

Note that the security requirements for the IT environment can contain both functional and assurance 
requirements. 

An example of a dependency on the IT environment is a software crypto-module, which periodically inspects 
its own code, and disables itself when the code has be^n tampered with. To allow for recovery, it has the 
requirement FPT_RCV.2 Automated recovery (automated recovery). As it cannot recover itself once it has 
disabled itself, this becomes a requirement on the IT environment. One of the dependencies of FPT_RCV.2 
Automated recovery is AGD_ADM.1 Administrator guidance (administrator guidance). This assurance 
requirement therefore becomes an assurance requirement for the IT environment. 

The evaluator is reminded that where security requirements for the IT environment refer to the TSF, they refer 
to the security functions of the environment, rather than security functions of the TOE. 

8.3.5.3.10 Work unit APE_REQ.1 -10 

ISO/IEC 15408-3 APE_REQ.1.6C: All completed operations on IT security requirements included in the PP 
shall be identified. 

The evaluator shall check that all completed operations on IT security requirements are identified. 

It is permissible for a PP to contain elements with uncompleted operations. That is, the PP can contain IT 
security requirement statements that include uncompleted operations for assignment or selection. The 
operations have then to be completed in an ST instantiating the PP. This gives the ST developer more 
flexibility in developing the TOE and the corresponding ST that claims compliance to a particular PP. 

The permitted operations for ISO/IEC 15408-2 and ISO/IEC 15408-3 components are assignment, iteration, 
selection and refinement. The assignment and selection operations are permitted only where specifically 
indicated in a component. Iteration and refinement are permitted for alt components. 

The evaluator determines that all operations are identified in each component where such an operation is 
used. Completed and uncompleted operations need to be identified in such a way, that they can be 
distinguished, and that it is clear whether the operation is completed or not. Identification can be achieved by 
typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. 

8.3.5.3.11 Work unit APE_REQ.1 -11 

The evaluator shall examine the statement of IT security requirements to determine that operations are 
performed correctly. 

The evaluator Is reminded that operations on security requirements need not be performed and completed in 
a PP. 

The evaluator compares each statement with the element from which it is derived to determine that: 

a) for an assignment, the values of the parameters or variables chosen comply with the indicated type 
required by the assignment; 
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b) for a selection, the selected item or items arp one or more of the items indicated within the selection 
portion of the element. The evaluator also defermines that the number of items chosen is appropriate for 
the requirement. Some requirements require a selection of just one item (e.g. FAU_GEN.1.1.b), in other 
cases multiple items (e.g. FDPJTT.1.1 second operation) are acceptable; 

c) for a refinement, the component is refined in such manner that a TOE meeting the refined requirement 
also meets the unrefined requirement. If the refined requirement exceeds this boundary it is considered to 
be an extended requirement; 

Example: ADV_SPM.1.2C The TSP model shall describe the rules and characteristics of all policies of the 
TSP that can be modelled. Refinement: The TSP model need cover only access control. If the access 
control policy is the only policy of the TSP this is a valid refinement. If there are also identification and 
authentication policies in the TSP, and the refinement is meant to state that only access control needs to 
be modeled, then this is aot a valid refinement. 

A special case of refinement is an editorial refinement, where a small change is made in a requirement, 
i.e. rephrasing a sentence due to adherence to proper English grammar. This change is not allowed to 
modify the meaning of the requirement in any way. 

An example of an editorial refinement is FAU_ARP.1 with a single action. Instead of writing: "The TSF 
shall take inform the operator upon detection of a potential security violation" the PP author is allowed to 
write: "The TSF shall inform the operator upon detection of a potential security violation". 

The evaluator is reminded that editorial refinements have to be clearly identified (see work unit 
APE_REQ.1-10). 

d) for an iteration, that each iteration of a component is different from each other iteration of that component 
(at least one element of a component is different from the corresponding element of the other component), 
or that the component applies to a different part of the TOE. 

8.3.5.3.12 Work unit APE_REQ.1 -12 

ISO/IEC 15408-3 APE_REQ.1.7C: Any uncompleted operations on IT security requirements included in the 
PP shall be identified. 

The evaluator shall examine the statement of IT security requirements to determine that all uncompleted 
operations are identified. 

The evaluator determines that all operafions are identified in each component where such an operation is 
used. Completed and uncompleted operafions need to be idenfified in such a way, that they can be 
distinguished, and that it is clear whether the operation is completed or not. Idenfificafion can be achieved by 
typographical distincfions, or by explicit idenfificafion in the surrounding text, or by any other distinctive means. 

8.3.5.3.13 Work unit APE_REQ.1 -13 

ISO/IEC 15408-3 APE_REQ.1.8C: Dependencies among the IT security requirements included in the PP 
should be satisfied. 

The evaluator shall examine the statement of IT security requirements to determine that dependencies 
required by the components used in the IT security requirements statement are satisfied. 

Dependencies may be satisfied by the inclusion of the relevant component (or one that is hierarchical to it) 
within the statement of TOE security requirements, or as a requirement that is asserted as being met by the IT 
environment of the TOE. 

Although ISO/IEC 15408 provides support for dependency analysis by inclusion of dependency, this is not a 
justificafion that no other dependencies exist. An example of such other dependencies is an element that 
refers to "all objects" or "all subjects", where a dependency could exist to a refinement in another element or 
set of elements where the objects or subjects are enumerated. 
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Dependencies of security requirements necessary in the IT environment should be stated and satisfied in the 
PP. 

The evaluator is reminded that ISO/IEC 15408 does not require all dependencies to be satisfied; see Vrie 
following work-unit. 

8.3.5.3.14 Work unit APE_REQ.1-14 

ISO/IEC 15408-3 APE_REQ.1.9C: The evidence shall justify why any non-satisfaction of dependencies is 
appropriate. 

The evaluator shall examine the security requirements rationale to determine that an appropriate justification 
is given for each case where security requirement dependencies are not satisfied. 

The evaluator determines that the justification explains why the dependency is unnecessary, given the 
identified security objectives. 

The evaluator confirms that any non-satisfaction of a dependency does not prevent the set of security 
requirements adequately addressing the security objectives. This analysis is addressed by APE_REQ.1.13C. 

An example of an appropriate justification is when a software TOE has the security objective: "failed 
authentications shall be logged with user identity, time and date" and uses FAU_GEN.1 Audit data generation 
(audit data generation) as a functional requirement to satisfy this security objective. FAU_GEN.1 Audit data 
generation contains a dependency on FPT_STM.1 Reliable time stamps (reliable time stamps). As the TOE 
does not contain a clock mechanism, FPT_STM.1 Reliable time stamps is defined by the PR author as a 
requirement on the IT environment. The PR author indicates that this requirement will not be satisfied with the 
justification: "there are attacks possible on the time-stamping mechanism in this particular environment, the 
environment can therefore not deliver a reliable time-stamp. Yet, some threat agents are incapable of 
executing attacks against the time-stamping mechanisms, and some attacks by these threat agents may be 
analysed by logging time and date of their attacks." 

8.3.5.3.1 5 Work unit APE_REQ.1 -1 5 

ISO/IEC 15408-3 APE_REQ.1.10C: The PP shall include a statement of the mininnum strength of function 
level for the TOE security functional requirements, either SOF-basic, SOF-medium or SOF-high, as 
appropriate. 

The evaluator shall check that the PP includes a statement of the minimum strength of function level for the 
TOE security functional requirements, and that this level is either SOF-basic, SOF-medium or SOF-high. 

If the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is rrot applicable and is therefore considered to be satisfied. 

The strength of cryptographic algorithms is outside the scope of ISO/IEC 15408. Strength of function only 
applies to probabilistic or permutational mechanisms that are non-cryptographic. Therefore, where an PP 
contains a minimum SOF claim this claim does not apply to any cryptographic mechanisms with respect to an 
ISO/IEC 15408 evaluation. Where such cryptographic mechanisms are included in a TOE the evaluator 
determines that the PP includes a clear statement that the assessment of algorithmic strength does not form 
part of the evaluation. 

The TOE may contain multiple distinct domains, where the PP writer deems it to be more applicable to have a 
minimum strength of function level for each domain, rather than having one overall minimum strength of 
function level for the entire TOE. in this case it is allowed to partition the TOE security functional requirements 
in distinct sets, and have different minimum strength of function levels associated with each set. 

An example of this is a distributed terminal system which has user terminals that are in a public space, and 
administrator terminats that are in a physically secure place. The authentication requirements for the user 
terminals have SOF-medium associated with them, and the authentication requirements for the administrative 
terminals have SOF-basic associated with them. Rather than stating that the TOE has a minimum strength of 
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function level of SOF-basic, which might lead potential consumers of the TOE to believe that it would be 
relatively easy to successfully attack the authentication mechanisms on user terminals, the PP writer divides 
the TOE into a user domain and an administrative domain, partitions the TOE security functional requirements 
into sets belonging to those domains, assigns a minimum strength of function level of SOF-basic to the set 
belonging to the administrative domain, and assigns a minimum strength of function level of SOF-medium to 
the set belonging to the user domain. 

8.3.5.3.16 Work unit APE_REQ.1 -16 

ISO/IEC 15408-3 APE_REQ.1.11C: The statement of security requirements shall Identify all security 
functional requirements for which an explicit strength of function claim is required, together with the explicit 
strength of function claim for each such security functional requirement. 

The evaluatbr shall check that the PP identifies any specific TOE security functional requirements for which an 
explicit strength of function is appropriate, together with the specific strength of function or metric as 
applicable. 

If the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is not applicable and is therefore considered to be satisfied. 

The explicit strength of function claim can be either SOF-basic, SOF-medium. SOF-high. or a defined specific 
metric. Where a specific metric is used, the evaluator determines that these are appropriate for the type of 
functional requirement specified, and that the metric specified is evaluatable as a strength claim. This work 
unit refers to the case where a PP author requires to set specific SOF requirements (i.e. higher than the 
overall SOF claim of the PP) or by using a metric. A specific SOF claim for a TOE security functional 
requirement may be specified by a PP author. In the absence of any specific claim, the overall claim for the 
PP applies for all TOE security functional requirements stated in the PP. The evaluator should confirm the 
presence or absence of explicit SOF claims is consistent with other parts of the PP. 

A PP could potentially have varying specifications of SOF claims. There can be an overall SOF claim for a PP 
and within a PP the TOE security functional requirements could have a SOF claim specified for it. 

Further guidance on appropriateness and suitability of strength of function metrics may be provided by the 
scheme. 

8.3.5.3.17 Work unit APE_REQ.1 -17 

1 SO/1 EC 15408-3 APE_REQ.1.12C: The security requirements rationale shall demonstrate that the minimum 
strength of function level for the PP, together with any explicit strength of function claim, is consistent with the 
security objectives for the TOE. 

The evaluator shall examine the security requirements rationale to determine that it demonstrates that the 
minimum strength of function level, together with any explicit strength of function claim, is consistent with the 
security objectives for the TOE. 

If the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is not applicable and is therefore considered to be satisfied. 

The evaluator determines that the rationale takes into account details about the likely expertise, resources, 
and motivation of attackers as described in the statement of TOE security environment. For example, a claim 
of SOF-basic is inappropriate if the TOE is required to provide defence against attackers who possess a high 
attack potential. 

The evaluator also determines that the rationale takes into account any specific strength-related properties of 
security objectives. The evaluator can use the tracings from requirements to objectives to determine that 
requirements that trace towards objectives with specific strength related properties, if appropriate, have a 
suitable strength of function claim associated with them. 
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8.3.5.3.18 Work unit APE_REQ.1 -18 

ISO/IEC 15408-3 APE_REQ.1.13C: The security requirements rationale shall demonstrate that the IT security 
requirements are suitable to meet the security objectives. 

The evaluator shall examine the security requirements rationale to determine that the TOE security 
requirements are traced back to the security objectives for the TOE. 

The evaluator determines that each TOE security functional requirement is traced back to at least oae security 
objective for the TOE. 

Failure to trace implies that either the security requirements rationale is Incomplete, the security objectives are 
incomplete, or that the TOE security functional requirement has no useful purpose. 

it is also allowed, but not mandatory, for some or all TOE security assurance requirements to trace back to 
security objectives for the TOE. 

An example of a TOE security assurance requirement tracing back to a security objective for the TOE is a PP 
containing the threat "A user unv/ittingly discloses information by using a device thinking it to be the TOE" and 
the security objective for the TOE "The TOE shall be clearly labelled with its version number" to counter that 
threat. This security objective for the TOE can be achieved by satisfying ACM_CAP.1 Version numbers and 
the PP author therefore traces ACM_GAP.1 Version numbers back to that security objective for the TOE. 

8.3.5.3.19 Work unit APE_REQ.i -19 

The evaluator shall examine the security requirements rationale to determine that the security requirements 
for the IT environment are traced back to the security objectives for the environment. 

The evaluator determines that each functional security requirement for the IT environment is traced back to at 
least one security objective for the environment. 

Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for 
the environment are incomplete, or that the functional security requirement for the IT environment has no 
useful purpose. 

It is also allowed, but not mandatory, for some or all security assurance requirements for the IT environment to 
trace back to security objectives for the environment. 

8.3.5.3.20 Work unit APE_REQ.1 -20 

The evaluator shall examine the security requirements rationale to determine that for each security objective 
for the TOE it contains an appropriate justification that the TOE security requirements are suitable to meet that 
security objective for the TOE. 

If no TOE security requirements trace back to the security objective for the TOE, this work unit fails. 

The evaluator determines that the justification for a security objective for the TOE demonstrates that if all TOE 
security requirements that trace back to the objective are satisfied, the security objective for the TOE is 
achieved. 

The evaluator also determines that each TOE security requirement that traces back to a security objective for 
the TOE, when satisfied, actually contributes to achieving the security objective. 

Note that the tracings from TOE security requirements to security objectives for the TOE provided in the 
security requirements rationale may be a part of the justification, but do not constitute a justification by 
themselves. 
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8.3.5.3.21 Work unit APE REQ.1-21 



The evaiuator shall examine the security requirements rationale to determine that for each security objective 
for the IT environment it contains an appropriate justification that the security requirements for the IT 
environment are suitable to meet that security objective for the IT environment. 

If no security requirements for the IT environment trace back to the security objective for the IT environment, 
this work unit fails. 

The evaiuator determines that the justification for a security objective for the environment demonstrates that if 
all security requirements for the IT environment that trace back to the security objective for the IT environment 
are satisfied, the security objective for the IT environment is achieved. 

The evaiuator also determines that each security requirement for the IT environment that traces back to a 
security objective for the IT environment, when satisfied, actually contributes to achieving the security 
objective. 

Note that the tracings from security requirements for the IT environment to security objectives for the IT 
environment provided in the security requirements rationale may be a part of a justification, but do not 
constitute a justification by themselves. 

8.3.5.3^2 Work unit APE_REQ.1 -22 

ISO/IEC 15408-3 APE_REQ.1.14C: The security requirements rationale shall demonstrate that the set of IT 
security requirements together forms a mutually supportive and internally consistent whole. 

The evaiuator shall examine the security requirements rationale to determine that it demonstrates that the set 
of IT security requirements is internally consistent. 

The evaiuator determines that on all accasions where different IT security requirements apply to the same 
types of events, operations, data, tests to be performed etc., and these requirements might conflict, an 
appropriate justification is provided that this is not the case. 

For example, if the PR contains requirements for individual accountability of users as well as requirements for 
user anonymity, it needs to be shown that these requirements do not conflict. This might involve showing that 
none of the auditable events requiring individual user accountability relate to operations for which user 
anonymity is required. 

For guidance on consistency analysis see A.3. Consistency analysis. 

8.3.5.3.23 Work unit APE_REQ.1 -23 

The evaiuator shall examine the security requirements rationale to determine that it demonstrates that the set 
of IT security requirements together forms a mutually supportive whole. 

This work unit builds on the determination performed in work units APE_REQ.1-18 and APE_REQ.1-19, which 
examine the tracing from IT security requirements to security objectives and work units APE_REQ.1-20 and 
APE_REQ.1-21 which examine whether the IT security requirements are suitable to meet the security 
objectives. This work unit requires the evaiuator to consider the possibility that a security objective might in 
fact not be achieved because of lack of support from other IT security requirements. 

This work unit also builds on the dependency analysis addressed by previous work units, because if functional 
requirement A has a dependency on functional requirement B, B supports A by definition. 

The evaiuator determines that the security requirements rationale demonstrates that functional requirements 
support each other where necessary, even when no dependency between these requirements is indicated. 
This demonstration should address security functional requirements that: 

a) prevent bypass of other security functional requirements, such as FPT_RVM.1 Non-bypassability of the 

TSP; 
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b) prevent tampering with other security functional requirements, such as Domain separation (FPT_SEP); 

c) prevent de-activation of other security functional requirements, such as FMT_M0F.1 Management of 
security functions behaviour; 

d) enable detection of attacks aimed at defeating other security functional requirements, such as 
components of the FAD: Security audit class. 

The evaluator takes the performed operations into account in his analysis to determine whether they affect the 
mutual support between the requirements. 

8.3.5.4 Action APE„REQ.1.2E 

8.3.5.4.1 Work unit APE_REQ.1-24 

The evaluator shall examine the statement of IT security requirements to determine thBt it is coherent. 

The statement of IT security requirements is coherent if the text and structure of the statement are 
understandable by its target audience (i.e. evaluators and consumers). 

8.3.5.4.2 Work unit APE_REQ.1 -25 

The evaluator shall examine the statement of IT security requirements to detemnine that it is complete. 

This work unit draws on the results from the work units required by APE_REQ.1 .1E and APE_SRE.1.1E, and 
in particular the evaluator's examination of the security requirements rationale. 

The statement of security requirements is complete if the evaluator judges the security requirements to be 
sufficient to ensure that all security objectives for the TOE are satisfied. 

8.3.5.4.3 Work unit APE_REQ.1-26 

The evaluator shall examine the statement of IT security requirements to determine that it is internally 
consistent. 

This work unit draws on the results from the work units required by APE_REQ.1.1E and APE_SRE.1.1E, and 
in particular the evaluator's examination of the security requirements rationale. 

The statement of security requirements is internally consistent if the evaluator determines that no security 
requirement conflicts with any other security requirement, such that a security objective will not be fully 
satisfied. 

For guidance on consistency analysis see A.3, Consistency analysis. 

8.3.6 Evaluation of Explicitly stated IT security requirements (APE_SRE.1) 

8.3.6.1 Objectives 

The objective of this sub-activity is to determine whether the security functional requirements or security 
assurance requirements that are stated without reference to ISO/IEC 15408 are appropriate and adequate. 

8.3.6.2 Input 

The evaluation evidence for this sub-activity is: 
a) the PP. 
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8.3.6.3 Application notes 



This subclause is only applicable if the PP contains IT security requirements that are explicitly stated without 
reference to either ISO/IEC 15408-2 or ISO/IEC 15408-3. If this is not the case, all work units in this subclause 
are not applicable, and therefore considered to be satisfied. 

The Explicitly stated IT security requirements (APE_SRE) requirements do not reptace the IT security 
requirements (APE_REQ) requirements, but are additional to them. This means that IT security requirements 
that are explicitly stated without reference to either ISO/IEC 15408-2 or ISO/IEC 15408-3 must be evaluated 
with the Explicitly stated IT security requirements (APE_SRE) criteria, and also, in combination with all other 
security requirements, with the IT security requirements (APE_REQ) criteria. 

8.3.6.4 Action APE_SRE.1 .1 E 

8.3.6.4.1 Work unit APE_SRE.1-1 

ISO/IEC 1 5408-3 APE_SRE. 1 . 1 C: A// TOE security requirements that are explicitly stated wittiout reference to 
ISO/IEC 15408 stiall be identified. 

The evaluator shall check that the statement of the IT security requirements identifies all TOE security 
requirements that are explicitly stated without reference to ISO/IEC 15408. 

Any TOE security functional requirements that are not specified using ISO/IEC 15408-2 functional 
components are required to be clearly identified as such. Similarly, any TOE security assurance requirements 
that are not specified using ISO/IEC 15408-3 assurance components are also required to be clearly identified 
as such. 

8.3.6.4.2 WorkunitAPE_SRE.1-2 

fSO/lEC 15408-3 APE_SRE.1.2C: All security requirements for ttie IT environment that are explicitly stated 
without reference to ISO/IEC 15408 shall be identified. 

The evaluator shall check that the statement of IT security requirements identifies all security requirements for 
the !T environment that are explicitly stated without reference to ISO/IEC 15408. 

Any security functional requirements for the IT environment that are not specified using ISO/tEC 15408-2 
functional components are required to be clearly identified as such. Similarly, any security assurance 
requirements for the IT environment that are not specified using ISO/IEC 15408-3 assurance components are 
also required to be clearly identified as such. 

8.3.6.4.3 Work unit APE_SRE.1-3 

ISO/IEC 1 5408-3 APE_SRE.1 .30: The evidence shall justify why the security requirements had to be explicitly 
stated. 

The evaluator shall examine the security requirements rationale to determine that it appropriately justifies why 
each explicitly stated IT security requirement had to be explicitly stated. 

The evaluator determines for each explicitly stated IT security requirement that the justification explains why 
existing functional or assurance components (from ISO/IEC 15408-2 and ISO/IEC 15408-3, respectively) 
could not be used to express the explicitly stated security requirement in question. The evaluator takes the 
possibility of performing operations (i.e. assignment, iteration, selection or refinement) on these existing 
components into account in this determination. 

8.3.6.4.4 Work unit APE_SRE.1-4 

ISO/IEC 15408-3 APE_SRE.1.4C: The explicitly stated IT security requirements shall use ISO/EC 15408 
requirements components, families and classes as a model for presentation. 
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The evaluator shall examine each explicitly stated IT security requirement to determine that the requirement 
uses ISO/IEC 15408 requirements components, families and classes as a model for presentation. 

The evaluator determines that explicitly stated IT security requirements are presented in the same style as 
ISO/IEC 15408-2 or ISO/IEC 15408-3 components and to a comparable level of detail. The evaluator also 
determines that the functional requirements are broken down into individual functional elements and that the 
assurance requirements specify the developer action, content and presentation of evidence, and evaluator 
action elements. 

8.3.6.4.5 Work unit APE_SRE.1 -5 

ISO/IEC 15408-3 APE_SRE.1.5C. The explicitly stated IT security requirements shall be measurable and 
state objective evaluation requirements such that compliance or noncompliance of a TOE can be determined 
and systematically demonstrated. 

The evaluator shall examine each explicitly stated IT security requirement to determine that it is measurable 
and states objective evaluation requirements, such that compliance or noncompliance of a TOE can be 
determined and systematically demonstrated. 

The evaluator determines that functional requirements are stated in such a way that they are testable, and 
traceable through the appropriate TSF representations. The evaluator also determines that assurance 
requirements avoid the need for subjective evaluator judgement. 

The existing ISO/IEC 15408 functional and assurance requirements are to be used as models for compliance 
with this requirement. 

8.3.6.4.6 WorkunitAPE_SRE.1-6 

ISO/IEC 15408-3 APE_SRE.1.6C: The explicitly stated IT security requirements shall be cleariy and 
unambiguously expressed. 

The evaluator shall examine each explicitly stated IT security requirement to determine that it is clearly and 
unambiguously expressed. 

The existing ISO/IEC 15408 functional and assurance requirements are to be used as models for compliance 
with this requirement. 

8.3.6.4.7 WorkunitAPE_SRE.1-7 

LSO/lEC 15408-3 APE_SRE.1.7C; The security requirements rationale shall demonstrate that the assurance 
requirements are applicable and appropriate to support any explicitly stated TOE security functional 
requirements. 

The evaluator shall examine the security requirements rationale to determine that it demonstrates that the 
assurance requirements are applicable and appropriate to support any explicitly stated TOE security 
functional requirements. 

The evaluator determines whether application of the specified assurance requirements will yield a meaningful 
evaluation result for each explicitly stated security functional requirement, or whether other assurance 
requirements should have been specified. For example, an explicitly stated functional requirement may imply 
the need for particular documentary evidence (such as a TSP model), depth of testing, or analysis (such as 
strength of TOE security functions analysis or covert channel analysis). 

8.3.6.5 Action APE_SRE.1 .2E 

8.3.6.5.1 WorkunitAPE_SRE.1-8 

The evaluator shall examine the statement of IT security requirements to determine that all of the 
dependencies of any explicitly stated IT security requirement have been identified. 
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The evaluator confirms that no applicable dependencies have been overlooked by the PP author. 

Examples of possible dependencies are: components of the FAD: Security audit class if an explrcitly stated 
functional requirement mentions auditing and Implementation representation (ADVJMP) if an explicitly stated 
assurance requirement mentions the source code or implementation representation of the TOE. 

9 Security Target evaluation 

9.1 Introduction 

This clause describes the evaluation of an ST. The ST evaluation is started prior to any TOE evaluation sub- 
activities since the ST provides the basis and context to perform these sub-activities. A final verdict on the ST 
may not be possible until the TOE evaluation is complete, since changes to the ST may result from sub- 
activity findings in the TOE evaluation. 

The requirements and methodology for ST evaluation are identical for each ST evaluation, regardless of the 
EAL (or other set of assurance criteria) that is claimed in the ST. While further clauses in this International 
Standard are targeted at performing evaluations at specific EALs, this clause is applicable to any ST that is 
evaluated. 

The evaluation methodology in this clause is based on the requirements of the ST as specified in ISO/IEC 
15408-1 especially Annex B, and ISO/IEC 15408-3 class ASE. 

9.2 ST evaluation relationships 

The activities to conduct a complete ST evaluation cover the following: 

a) evaluation input tasl< (Clause 7); 

b) ST evaluation activity, comprising the following sub-activities: 

1) evaluation of the TOE description (Subclause 9.3.1); 

2) evaluationof the security environment (Subclause 9.3.2); 

3) evaluation of the ST introduction (Subclause 9.3.3); 

4) evaluation of the security objectives (Subclause 9.3.4); 

5) evaluation of the PP claims (Subclause 9.3.5); 

6) evaluation of the IT security requirements (Subclause 9.3.6); 

7) evaluation of the explicitly stated IT security requirements (Subclause 9,3.7); 

8) evaluation of the TOE summary specification (Subclause 9.3.8). 

c) evaluation output task (Clause 7). 

The evaluation input and evaluation output tasks ^re described in Clause 7. The evaluation activities are 
derived from the ASE assurance requirements contained in ISO/IEC 15408-3. 

The sub-activities comprising an ST evaluation are described in this clause. Although the sub-activities can, in 
general, be started more or less coincidentally, some dependencies between sub-activities have to be 
considered by the evaluator. For guidance on dependencies see A.4, Dependencies. 

The evaluation of the PP claims and the evaluation of the explicitly stated IT security requirements sub- 
activities do not always have to be performed: the evaluation of the PP claims sub-activity applies only if a PP 
claim is made, and the evaluation of the explicitly stated IT security requirements sub-activity applies only if 
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security requirements not taken from ISO/IEC 15408-2 or ISO/IEC 15408-3 are included in the IT security 
requirements statement. 

Some of the information required for the ST may be included by reference. For example if compliance to a PP 
is claimed, the information in the PP such as the information about the environment and threats is considered 
to be part of the ST and should conform to the criteria for the ST. 

If the ST claims compliance with an evaluated PP, and is largely based on the content of that PP, then it may 
be possible to reuse the PP evaluation results in performing many of the sub-activities listed above. In 
particular, reuse may be possible when evaluating the statement of security environment, the security 
objectives and IT security requirements. It is allowed for an ST to claim compliance with multiple PPs. 

9.3 Security Target evaluation activity 

9.3.1 Evaluation of TOE description (ASE_DES.1) 

9.3.1.1 Objectives 

The objective of this sub-activity is to determine whether the TOE description contains relevant infonnation to 
aid the understanding of the purpose of the TOE and its functionality, and to determine whether the 
description is complete and consistent. 

9.3.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.1.3 Application notes 

There may be a difference between a TOE and a product that a consumer might purchase. A discussion on 
this subject can be found in A.6, TOE Boundary. 

9.3.1.4 Action ASE_DES.1.1E 

9.3.1.4.1 Work unit ASE_DES. 1-1 

ISO/IEC 15408-3 ASE_DES.1.1C; The TOE description sfiall describe the product or system type, arid the 
scope and boundaries of the TOE in general terms both in a physical and a logical way . 

The evaluator shall examine the TOE description to determine that it describes the product or system type of 

the TOE. 

The evaluator determines that the TOE description is sufficient to give the reader a general understanding of 
the intended usage of the product or system, thus providing a context for the evaluation. Some examples of 
product or system types are: firewall, smartcard, crypto-modem, web server, intranet. 

There are situations where it is clear that some functionality is expected of the TOE because of its product or 
system type. If this functionality is absent, the evaluator determines whether the TOE description adequately 
discusses this absence. An example of this is a firewall-type TOE, whose TOE description states that It cannot 
be connected to networks. 

9.3.1 .4.2 WoTk unit ASE_DES.1 -2 

The evaluator shall examine the TOE description to determine that it describes the physical scope and 
boundaries of the TOE in general terms. 
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The evaluator determines that the TOE description discusses the hardware, firmware and software 
components and/or modules that constitute the TOE at a level of detail that is sufficient to give the reader a 
general understanding of those components and/or modules. 

If the TOE is not identical to a product, the evaluator determines that the TOE description adequately 
describes the physical relationship between the TOE and the product. 

9.3.1 .4.3 Work unit ASE_DES.1 -3 

The evaluator shall examine the TOE description to determine that it describes the logical scope and 
boundaries of the TOE in general terms. 

The evaluator determines that the TO^ description discusses the IT, and in particular the security features 
offered by the TOE at a level of detail that is sufTicient to give the reader a general understanding of those 
features. 

If the TOE is not identical to a product, the evaluator determines that the TOE description adequately 
describes the logical relationship between the TOE and the product. 

9.3.1 .5 Action ASE_DES.1 .2E 

9.3.1.5.1 Worl(unitASE_DES.1-4 

The evaluator shall examine the ST to determine that the TOE description is coherent. 

The statement of the TOE description is coherent if the text and structure of the statement are understandable 
by its target audience (i.e. evaluators and consumers). 

9.3.1 .5.2 Work unit ASE_DES.1 -5 

The evaluator shall examine the ST to determine that the TOE description is internally consistent. 

The evaluator is reminded that this subclause of the ST is only intended to define the general intent of the 
TOE. 

For guidance on consistency analysis see A.3, Consistency analysis. 

9.3.1.6 Action ASE_DES.1.3E 
9.3.1 .6.1 Work unit ASE_DES.1 -6 

The evaluator shall examine the ST to determine that the TOE description is consistent with the other parts of 

the ST. 

The evaluator determines in particular that the TOE description does not describe threats, security features or 
configurations of the TOE that are not considered elsewhere in the ST. 

For guidance on consistency analysis see A.3, Consistency analysis. 

9.3.2 Evaluation of Security environment (ASE_ENV.1) 

9.3.2.1 Objectives 

The objective of this sub-activity is to determine whether the statement of TOE security environment in the ST 
provides a clear and consistent definition of the security problem that the TOE and its environment is intended 
to address. 
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9.3.2.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.2.3 Action ASE_ENV.1.1E 

9.3.2.3.1 Work unit ASE_ENV.1-1 

ISO/IEC 15408-3 ASE_ENV.1.1C: The statement of TOE security environment shall identify and explain any 
assumptions about the intended usage of the TOE and the environment of use of the TOE. 

The evaluator shall examine the statement of TOE security environment to determine that it identifies and 
explains any assumptions. 

The assumptions can be partitioned into assumptions about the intended usage of the TOE, and assumptions 
about the environment of use of the TOE. 

The evaluator determines that the assumptions about the intended usage of the TOE address aspects such 
as the Intended application of the TOE, the potential value of the assets requiring protection by the TOE, and 
possible limitations of use of the TOE. 

The evaluator determines that each assumption about the intended usage of the TOE is explained in sufficient 
detail to enable consumers to determine that their intended usage matches the assumption. If the 
assumptions are not clearly understood, the end result may be that consumers will use the TOE in an 
environment for which It is not intended. 

The evaluator determines that the assumptions about the environment of use of the TOE cover the physical, 
personnel, and connectivity aspects of the environment: 

a) Physical aspects include any assumptions that need to be made about the physical location of the TOE or 
attached peripheral devices in order for the TOE to function in a secure way. Some examples: 

• it is assumed that administrator consoles are in an area restricted to only administrator personnel; 

• it is assumed that all file storage for the TOE is done on the workstation that the TOE runs on. 

b) Personnel aspects include any assumptions that need to be made about users and administrators of the 
TOE, or other individuals (including potential threat agents) within the environment of the TOE in order for 
the TOE to function in a secure way. Some examples: 

• it is assumed that users have particular skills or expertise; 

• it is assumed that users have a certain minimum clearance; 

• it is assumed that administrators will update the anti-virus database monthly. 

c) Connectivity aspects include any assumptions that need to be made regarding connections between the 
TOE and other IT systems or products (hardware, software, firmware or a combination thereof) that are 
external to the TOE in order for the TOE to function in a secure way. Some examples: 

• it is assumed that at least 100MB of external disk space is available to store logging files generated by 
a TOE; 

• the TOE is assumed to be the only non-operating system application being executed at a particular 
workstation; 

• the floppy drive of the TOE is assumed to be disabled; 

• it is assumed that the TOE will not be connected to an untrusted network. 
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The evaluator determines that each assumption about the environment of use of the TOE is explained In 
sufficient detail to enable consumers to determine that their intended environment matches the environmental 
assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an 
environment in which It will not function in a secure manner. 

9.3.2.3.2 Work unit ASE_ENV.1'2 

ISO/IEC 15408-3 ASE_ENV.1 .2C: The statement of TOE security environment shall Identify and explain any 
known or presumed threats to the assets against which protection will be required, either by the TOE or by its 
environment 

The evaluator shall examine the statement of TOE security environment to determine that it identifies and 
explains any threats. 

If the security objectives for the TOE and Its environment are derived from assumptions and organisational 
security policies only, the statement of threats need not be present In the ST. In this case, this work unit is not 
applicable and therefore considered to be satisfied. 

The evaluator determines that all identified threats are clearly explained in terms of an identified threat agent, 
the attack, and the asset that is the subject of the attack. 

The evaluator also determines that threat agents are characterised by addressing expertise, resources, and 
motivation and that a ttacks are characterised by attack methods, any vulnerabilities exploited, and 
opportunity. 

9.3.2.3.3 WorkunltASE_ENV.1-3 

ISO/IEC 15408-3 ASE_ENV.1.3C: The statement of TOE security environment shall identify and explain any 
organisational security policies with which the TOE must comply. 

The evaluator shall examine the statement of TOE security environment to determine that it identifies and 
explains any organisational security policies. 

If the security objectives for the TOE and Its environment are derived from assumptions and threats only, 
organisational security policies need not be present in the ST. In this case, this work unit is not applicable and 
therefore considered to be satisfied. 

The evaluator determines that organisational security policy statements are made in terms of rules, practices 
or guidelines that must be followed by the TOE or its environment, as laid down by the organisation controlling 
the environment in which the TOE is to be used. An example organisational security policy is a requirement 
for password generation and encryption to conform to a standard stipulated by a national government. 

The evaluator determines that each organisational security policy is explained and/or interpreted in sufficient 
detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit 
tracing security objectives to them. 

9.3.2.4 Action ASE_ENV.1.2E 

9.3.2.4.1 Work unit ASE_ENV.1 -4 

The evaluator shall examine the statement of TOE security environment to determine that it is coherent. 

The statement of the TOE security environment is coherent if the text and structure of the statement are 
understandable by its target audience (I.e. evaluators and consumers). 
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9.3.2.4.2 Work unit ASE„ENV.1 -5 

The evaluator shall examine the statement of TOE security environment to determine that It is Internally 
consistent. 

Examples of internally inconsistent statements of TOE security environment are: 

• a statement of TOE security environment that contains a threat where the attack method is not within the 
capability of its threat agent; 

• a statement of TOE security environment that contains an organisational security policy "The TOE shall 
not be connected to the Internet" and a threat where the threat agent is an intruder from the Internet. 

For guidance on consistency analysis see A.3, Consistency analysis. 

9.3.3 Evaluation of ST introduction (ASEJNT.1) 

9.3.3.1 Objectives 

The objective of this sub-activity is to determine whether the ST introduction is complete and consistent with 
all parts of the ST and whether it correctly identifies the ST. 

9.3.3.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.3.3 Action ASE_INT.1.1E 

9.3.3.3.1 Worit unit ASEJNT. 1-1 

ISO/IEC 15408-3 ASE_INT.1.1C: The ST introduction stiall contain an ST identification that provides the 
labelling and descriptive information necessary to control and identify the ST and the TOE to which it refers. 

The evaluator shall check that the ST introduction provides ST identification information necessary to control 
and identify the ST and the TOE to which it refers. 

The evaluator determines that the ST identification information includes: 

a) information necessary to control and uniquely identify the ST (e.g. title of the ST, version number, 
publication date, authors); 

b) information necessary to control and uniquely identify the TOE to which the ST refers (e.g. identity of the 
TOE, version number of the TOE); 

c) indication of the version of ISO/IEC 15408 used to develop the ST; 

d) additional information, as required by the scheme. 

9.3.3.3.2 Work unit ASEJNT.1-5 

ISO/IEC 15408-3 ASE_INT.1 .2C: The ST introduction shall contain an ST overvievi/ which sumnriarises the ST 
in narrative form. 

The evaluator shall check that the ST introduction provides an ST overview in narrative form. 
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The ST overview is intended to provide a brief summary of the content of the ST (a more detailed description 
is provided in the TOE description) that is sufficiently detailed to enable a potential consumer to determine 
whether the TOE (and therefore the rest of the ST) is of interest. 

9.3.3.3.3 Work unit ASEJNT.1-3 

ISO/IEC 15408-3 ASE_INT.1.3C: The ST introduction stiall contain an ISO/IEC 15408 conformance claim that 
states any evaluatable claim of ISO/IEC 15408 conformance for the TOE. 

The evaluator shall check that the ST introduction contains an ISO/IEC 15408 conformance claim that states a 
claim of ISO/IEC 15408 conformance for the TOE. 

The evaluator determines that ISO/IEC 15408 conformance claim is in accordance with subclause 6 4 of 
ISO/IEC 15408-1. 

The evaluator determines that ISO/IEC 15408 conformance claim contains either ISO/IEC 15408-2 
conformant or ISO/IEC 154Q8-2 extended. 

The evaluator determines that ISO/IEC 15408 conformance claim contains either ISO/IEC 15408-3 
conformant or ISO/IEC 15408-3 extended. 

if ISO/IEC 15408-3 extended is claimed and the assurance requirements package includes assurance 
requirements in ISO/IEC 15408-3, the evaluator determines that ISO/IEC 15408 conformance claim states 
which assurance requirements that are in ISO/IEC 15408-3 are claimed. 

If Package Name conformant is claimed, the evaluator determines that ISO/IEC 15408 conformance claim 
states which package is claimed. 

If Package Name augmented is claimed, the evaluator determines that ISO/IEC 15408 conformance claim 
states which package is claimed and which augmentations to that package are claimed. 

If PP conformant is claimed, the evaluator determines that ISO/IEC 15408 conformance claim states to which 
PP or PPs conformance is claimed. 

The evaluator is reminded that if conformance to a PP Is claimed the Evaluation of PP claims (ASE_PPC.1) 
criteria apply and that if either ISO/IEC 15408-2 extended or ISO/IEC 15408-3 extended is claimed the 
Evaluation of Explicitly stated IT security requirements (ASE_SRE.1) criteria apply. 

9.3.3.4 Action ASEJNT.1.2E 

9.3.3.4.1 Work unit ASEJNT.1 ^ 

The evaluator shall examine the ST introduction to determine that it is coherent. 

The ST introduction is coherent if the text and structure of the statement are understandable by its target 
audience (i.e. evaiuators and consumers). 

9.3.3.4.2 Work unit ASEJNT.1-5 

The evaluator shall examine the ST introduction to determine that it is internally consistent. 

The internal consistency analysis will naturally focus on the ST overview that provides a summary of the 
content of the ST. 

For guidance on consistency analysis see A.3, Consistency analysts. 
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9.3.3.5 Action ASEJNT.1.3E 
9.3.3.5.1 WorkunitASE_INT.1-6 

The evaluator shall examine the ST to determine that the ST introduction is consistent with the other parts of 

the ST. 

The evaluator determines that the ST overview provides an accurate summary of the TOE. In particular, the 
evaluator determines that the ST overview is consistent with the TOE description, and that it does not state or 
imply the presence of security features that are not in the scope of evaluation. 

The evaluator also determines that ISO/lEC 15408 conformance claim is consistent with the rest of the ST. 

For guidance on consistency analysis see A. 3, Consistency analysis. 

9.3.4 Evaluation of Security objectives (ASE_0BJ.1) 

9.3.4.1 Objectives 

The objective of this sub-activity is to determine whether the security objectives are described completely and 
consistently, and to determine whether the security objectives counter the identified threats, achieve the 
identified organisational security policies and are consistent with the stated assumptions. 

9.3.4.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.4.3 Action ASE_0BJ.1. IE 

9.3.4.3.1 Work unit ASE_0BJ.1-1 

ISO/lEC 15408-3 ASE_OBJ.1 .IC: The statement of security objectives shall define the security objectives for 
the TOE and its environment. 

The evaluator shall check that the statement of security objectives defines the security objectives for the TOE 
and its environment. 

The evaluator determines that for each security objective it is clearly specified whether it is intended to apply 
to the TOE, to the environment, or both. 

9.3.4.3.2 WorkunitASE_OBJ.1-2 

ISO/lEC 15408-3 ASE_0BJ.1.2C: The security objectives for the TOE shall be traced back to aspects of the 
identified threats to be countered by the TOE and/or organisational security policies to be met by the TOE. 

The evaluator shall examine the security objectives rationale to determine that all security objectives for the 
TOE are traced back to aspects of the identified threats to be countered and/or aspects of the organisational 
security policies to be met by the TOE. 

The evaluator determines that each security objective for the TOE is traced back to at least one threat or 
organisational security policy. 

Failure to trace implies that either the security objectives rationale is incomplete, the threats or organisational 
security policy statements are incomplete, or the security objective for the TOE has no useful purpose. 
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9.3.4.3.3 Work unit ASE OBJ.1-3 



iSO/lEC 15408-3 ASE_0BJ.1 .3C: The security objectives for the environment shall be traced back to aspects 
of identified threats not completely countered by the TOE and/or organisational security policies or 
assumptions not completely met by the TOE. 

The evaluator shall examine the security objectives rationale to determine that the security objectives for the 
environment are traced back to aspects of the identified threats to be countered by the TOE's environment 
and/or aspects of the organisational security policies to be met by the TOE's environment and/or assumptions 
to be met in the TOE's environment. 

The evaluator determines that each security objective for the environment is traced back to at least one 
assumption, threat or organisational security policy. 

Failure to trace implies that either the security objectives rationale is incomplete, the threats, assumptions or 
organisational security policy statements are incomplete, or the security objective for the environment has no 
useful purpose. 

A threat may therefore be addj-essed entirely by one or more objectives for the environment. An extreme case 
would be where there are no security objectives for the TOE. Whilst this remains a valid use of the PP/ST 
construct, a TOE for which all threats and OSPs are addressed by the environment would be of questionable 
utility, as for such a TOE there would be no security functional requirements for the TOE. 
Certification/validation of such a TOE is a scheme issue. 

9.3.4.3.4 Work unit ASE_OBJ. 1-4 

ISO/IEC 15408-3 ASE_0BJ.1 .4C: The security objectives rationale shall demonstrate that the stated security 
objectives are suitable to counter the identified threats to security. 

The evaluator shall examine the security objectives rationale to determine that for each threat it contains an 
appropriate justification that the security objectives are suitable to counter that threat. 

If no security objectives trace back to the threat, this work unit fails. 

The evaluator determines that the justification for a threat demonstrates that if all security objectives that trace 
back to the threat are achieved, the threat is removed, the threat is diminished to an acceptable level, or the 
effects of the threat are sufficiently mitigated. 

The evaluator also determines that each security objective that traces back to a threat, when achieved, 
actually contributes to the removal, diminishing or mitigation of that threat. 

Examples of removing a threat are: 

• removing the ability to use an attack method from an agent; 

• removing the motivation of a threat agent by deterrence; 

• removing the threat agent (e.g. removing machines from a network that frequently crash that network). 
Examples of diminishing a threat are: 

• restricting the threat agent in attack methods; 

• restricting the threat agents in opportunity; 

• reducing the likelihood of a launched attack being successful; 

• requiring greater expertise or greater resources from the threat agent. 
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Examples of mitigating the effects of a threat are: 

• making frequent back-ups of the asset; 

• having spare copies of a TOE; 

• frequent changing of keys used in a communication session, so that the effects of breaking one key are 
relatively minor. 

Note that the tracings from security objectives to threats provided in the security objectives rationale may be a 
part of a justification, but do not constitute a justification by themselves. Even in the case that a security 
objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a 
justification is required, but this justification could be quite minimal in this case, 

9.3.4.3.5 Work unit ASE_OBJ. 1-5 

ISO/fEC 15408-3 ASE_0BJ.1 .5C: The security objectives rationale shall demonstrate that the stated security 
objectives are suitable to coverall of the identified organisational security policies and assumptions. 

The evaluator shall examine the security objectives rationale to determine that for each organisational security 
policy it contains an appropriate justification that the security objectives are suitable to cover that 
organisational security policy. 

If no security objectives trace back to the organisational security policy, this work unit fails. 

The evaluator determines that the justification for an organisational security policy demonstrates that if all 
security objectives that trace back to that organisational security policy are achieved, the organisational 
security policy is implemented. 

The evaluator also determines that each security objective that traces back to an organisational security policy, 
when achieved, actually contributes to the implementation of the organisational security policy. 

Note that the tracings from security objectives to organisational security policies provided in the security 
objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in 
the case that a security objective is merely a statement reflecting the intent to implement a particular 
organisational security policy, a justification is required, but this justification could be quite minimal in this case. 

9.3.4.3.6 Work unit ASE_0BJ.1-6 

The evaluator shall examine the security objectives rationale to determine that for each assumption it contains 
an appropriate justification that the security objectives for the environment are suitable to cover that 
assumption. 

If no security objectives for the environment trace back to the assumption, this work unit fails. 

An assumption is either an assumption about the intended usage of the TOE, or an assumption about the 
environment of use of the TOE. 

The evaluator determines that the justification for an assumption about the intended usage of the TOE 
demonstrates that if all security objectives for the environment that trace back to that assumption are achieved, 
the intended usage is supported. 

The evaluator also determines that each security objective for the environment that traces back to an 
assumption about the intended usage of the TOE, when achieved, actually contributes to the support of the 
intended usage. 

The evaluator determines that the justification for an assumption about the environment of use of the TOE 
demonstrates that if all security objectives for the environment that trace back to that assumption are achieved, 
the environment is consistent with the assumption. 
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The evaluator also determines that each security objective for the environment that traces back to an 
assumption about the environment of use of the TOE, when achieved, actually contributes to the environment 
achieving consistency with the assumption. 

Note that the tracings from security objectives for the environment to assumptions provided in the security 
objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in 
the case that a security objective of the environment is merely a restatement of an assumption, a justification 
is required, but this justification could be quite minimal in this case, 

9.3.4.4 Action ASE_0BJ.1.2E 

9.3.4.4.1 Work unit ASE_0BJ.1-7 

The evaluator shall examine the statement of security objectives to determine that it is coherent. 

The statement of security objectives is coherent if the text and structure of the statement are understandable 
by its target audience (i.e. evaluators and consumers). 

9.3.4.4.2 WorkumtASE_OBJ.1-8 

The evaluator shall examine the statement of security objectives to determine that it is complete. 

The statement of security objectives is complete if the security objectives are sufficient to counter all identified 
threats, and cover all identified organisational security policies and assumptions. This work unit may be 
performed in conjunction with the ASE_0BJ.1-4, ASE_0BJ.1-5 and ASE_0BJ.1-6 work units. 

9.3.4.4.3 Work unit ASE_0BJ.1 -9 

The evaluator shall examine the statement of security objectives to determine that it is internally consistent. 

The statement of security objectives is internally consistent if the security objectives do not contradict each 
other. An example of such a contradiction could be two security objectives as "a user's identity shall never be 
released", and "a user's identity shall be available to the other users". 

For guidance on consistency analysis see A. 3, Consistency analysis. 

9.3.5 Evaluation of PP claims (ASE_PPC.1 ) 

9.3.5.1 Objectives 

The objective of this sub-activity is to determine whether the ST is a correct instantiation of any PP for which 
compliance is being claimed. 

9.3.5.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the PP(s) that the ST claims compliance to. 

9.3.5.3 Application notes 

This subclause is only applicable if the ST claims compliance with one or more PPs. If the ST does not claim 
compliance with one or more PPs, all work units in this subclause are not applicable, and therefore considered 
to be satisfied. 
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9.3.5.4 Action ASE_PPC.1. IE 

9.3.5.4.1 Work unit ASE_PPC.1-1 

ISO/IEC 1 5408-3 ASE_PPC.1 .1C: Each PP claim shall identify the PP for which compliance is being claimed, 
including qualifications needed for that claim. 

The evaluator shall check that each PP claim identifies the PP for which compliance is being claimed. 

The evaluator determines that any referenced PPs are unambiguously identified (e.g. by title and version 
number, or by the identification included in the introduction of that PP). The evaluator is reminded that claims 
of partial compliance to a PP are not permitted under ISO/IEC 15408. 

9.3.5.4.2 Work unit ASE_PPC.1 -2 

ISO/IEC 15408-3 ASE_PPC.1.2C: Each PP claim shall identify the IT security requirements statements that 
satisfy the permitted operations of the PP or otherwise further qualify the PP requirements. 

The evaluator shall check that each PP claim identifies the IT security requirements statements that satisfy the 
permitted operations of the PP or othenwise further qualify the PP requirements. 

The ST does not need to repeat statements of security requirements that are included in a PP that are 
unmodified for this ST. If, however, the PP security functional requirements include uncompleted operations, 
or the ST author has applied the refinement operation on any PP security requirement, then these 
requirements in the ST must be clearly identified. 

9.3.5.4.3 Work unit ASE_PPC.1-3 

ISO/IEC 15408-3 ASE_PPC.1.3C: Each PP claim shall identify security objectives and IT security 
requirements statements contained in the ST that are in addition to those contained in the PP. 

The evaluator shall check that each PP claim identifies those security objectives and IT security requirements 
that are additional to the security objectives and the IT security requirements contained in the PP. 

The evaluator determines that all security objectives and security requirements that are included in the ST, but 
were not included in the PP, are clearly identified. 

9.3.5.5 Action ASE_PPC.1.2E 

9.3.5.5.1 WorkunitASE_PPC.1-4 

For each PP claim, the evaluator shall examine the ST to determine that all operations that were performed on 
the IT security requirements from the PP are within the bounds set by the PP. 

This work unit covers not only the uncompleted assignment or selection operations in the PP, but also any 
application of the refinement operation on the security requirements taken from the PP. 

9.3.6 Evaluation of IT security requirements (ASE_REQ.1) 

9.3.6.1 Objectives 

The objective of this sub-activity is to determine whether the TOE security requirements (both the TOE 
security functional requirements and the TOE security assurance requirements) and the security requirements 
for the IT environment are described completely and consistently, and that they provide an adequate basis for 
development of a TOE that will achieve its security objectives. 
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9.3.6.2 input 

The evaluation evidence for this sub-activity is; 
a) the ST. 

9.3.6.3 Action ASE_REQ.1 .1 E 

9.3.6.3.1 Work unit ASE_REQ.1 -1 

iSO/lEC 15408-3 ASE_REQ.1.1C: The statement of TOE security functional requirements shall identify the 
TOE security functional requirements drawn from ISO/IEC 15408-2 functional requirements components. 

The evaluator shall checl^ the statement of TOE security functional requirements to determine that it identifies 
the TOE security functional requirements drawn from ISO/IEC 15408-2 functional requirements components. 

The evaluator determines that all TOE security functional requirements components drawn from ISO/IEC 
15408-2 are identified, either by reference to an individual component in ISO/IEC 15408-2, or by reference to 
an individual component in a PP that the ST claims to be compliant with, or by reproduction in the ST. 

9.3.6.3.2 Worit unit ASE_REQ.1-2 

The evaluator shall check that each reference to a TOE security functional requirement component is correct. 

The evaluator determines for each reference to a ISO/IEC 15408-2 TOE security functional requirement 
component whether the referenced component exists in ISO/IEC 1 5408-2. 

The evaluator determines for each reference to a TOE security functional requirement component in a PP 
whether the referenced component exists in that PP, 

9.3.6.3.3 Work unit ASE_REQ.1 -3 

The evaluator shall check that each TOE security functional requirement component that was drawn from 
iSO/lEC 15408-2 that was reproduced in the ST, is correctly reproduced. 

The evaluator determines that the requirements are correctly reproduced in the statement of TOE security 
functional requirements without examination for permitted operations. The examination for correctness of 
component operations will be performed in the ASE_REQ.1-1 1 and ASE_REQ. 1-12 work units. 

9.3.6.3.4 Work unit ASE_REQ.1-4 

ISO/IEC 15408-3 ASE_REQ.1.2C: The statement of TOE security assurance requirements shall identify the 
TOE security assurance requirements drawn from ISO/IEC 15408-3 assurance requirements components. 

The evaluator shall check the statement of TOE security assurance requirements to determine that it identifies 
the TOE security assurance requirements drawn from ISO/IEC 15408-3 assurance requirements components. 

The evaluator determines that all TOE security assurance requirements components drawn from ISO/IEC 
15408-3 are identified, either by reference to an EAL, or by reference to an individual component in ISO/IEC 
15408-3, or by reference to a PP that the ST claims to be compliant with, or by reproduction in the ST. 

9.3.6.3.5 Work unit ASE_REQ.1-5 

The evaluator shall check that each reference to a TOE security assurance requirement component is correct. 

The evaluator determines for each reference to a ISO/IEC 15408-3 TOE security assurance requirement 
component whether the referenced component exists in ISO/IEC 15408-3. 

The evaluator determines for each reference to a TOE security assurance requirement component in a PP 
whether the referenced component exists in that PP. 
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9.3.6.3.6 Work unit ASE_REQ.1 -6 

The evaluator shall check that each TOE security assurance requirement component that was drawn from 
ISO/IEC 15408-3 that was reproduced in the ST, is correctly reproduced. 

The evaluator determines that the requirements are correctly reproduced in the statement of TOE security 
assurance requirements without examination for permitted operations. The examination for correctness of 
component operations will be performed in the ASE_REQ.1-1 1 and ASE_REQ.1-12 work units. 

9.3.6.3.7 Work unit ASE_REQ.1-7 

ISO/IEC 15408-3 ASE_REQ.1.3C: The statement of TOE security assurance requirements should include an 
Evaluation Assurance Level (EAL) as defined in ISO/IEC 15408-3. 

The evaluator shall examine the statement of TOE security assurance requirements to determine that either it 
includes an EAL as defined in ISO/IEC 15408-3 or appropriately justifies that it does not include an EAL. 

If no EAL is included, the evaluator determines that the justification addresses why the statement of TOE 
assurance requirements contains no EAL. This justification may address the reason why it was impossible, 
undesirable or inappropriate to include an EAL, or it may address why it was impossible, undesirable or 
inappropriate to include particular components of the families that constitute EAL1 (CM capabilities 
{ACM_CAP), Installation, generation and start-up (ADOJGS), Functional specification (ADV_FSP), 
Representation correspondence (ADV_RCR), Administrator guidance (AGD_ADM), User guidance 
(AGD_USR), and Independent testing (ATEJND)). 

9.3.6.3.8 Work unit ASE_REQ.1 -8 

ISO/IEC 15408-3 ASE_REQ.1.4C: The evidence shall justify that the statement of TOE security assurance 
requirements is appropriate. 

The evaluator shall examine the security requirements rationale to determine that it sufficiently justifies that 
the statement of TOE security assurance requirements is appropriate. 

If the assurance requirements contain an EAL, the justification is allowed to address the choice of that EAL as 
a whole, rather than addressing all individual components of that EAL. If the assurance requirements contain 
augmented components to that EAL, the evaluator determines that each augmentation is individually Justified. 
If the assurance requirements contain explicitly stated assurance requirements, the evaluator determines that 
the use of each explicitly stated assurance requirement is individually justified. 

The evaluator determines that the security requirements rationale sufficiently justifies that the assurance 
requirements are sufficient given the statement of security environment and security objectives. For example, 
if defence against knowledgeable attackers is required, then it would be inappropriate to specify AVA_VLA.1 
which is unlikely to detect other than obvious security weaknesses. 

The justification may also include reasons such as; 

a) the assurance requirements that appear in PPs that the ST claims conformance to; 

b) specific requirements imposed by the scheme, national government, or other organisations; 

c) assurance requirements that were dependencies from TOE security functional requirement; 

d) assurance requirements of systems and/or products that are to be used in conjunction with the TOE; 

e) consumer requirements. 

An overview of the intent and goals of each EAL is provided in ISO/IEC 15408-3 subclause 10.2. 
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The evaluate: is reminded that determining whether the assurance requirements are appropriate may be 
subjective and that the analysis of sufficiency of the justification should therefore not be overly rigorous. 

If the assurance requirements do not contain an EAL, this work unit may be performed in conjunction with the 
ASE_REQ.1-7 work unit. 

9.3.6.3.9 Work unit ASE_REQ.1-9 

ISO/IEC 15408-3 ASE„REQ.1.5C: The ST shall, if appropriate, identify any security requirements for the IT 
environment. 

The evaluator shall check that security requirements for the IT environment are identified, if appropriate. 

If the ST does not contain security requirements for the IT environment, this work unit is not applicable and 
therefore considered to be satisfied. 

The evaluator determines that any dependencies of the TOE on other IT in its environment to provide any 
security functionality in order for the TOE to achieve its security objectives are clearly identified in the ST as 
security requirements for the IT environment. 

An example of a security requirement for the IT environment is a firewall that relies on an underlying operating 
system to provide authentication of administrators and permanent storage of audit data. In this case, the 
security requirements for the IT environment would contain components from the FAU: Security audit and FIA: 
Identification and authentication classes. 

Note that the security requirements for the IT environment can contain both functional and assurance 
requirements. 

An example of a dependency on the IT environment is a software crypto-module. which periodically inspects 
its own code, and disables itself when the code has been tampered with. To allow for recovery, it has the 
requirement FPT_RCV.2 Automated recovery (automated recovery). As it cannot recover Itself once it has 
disabled itself, this becomes a requirement on the IT environment. One of the dependencies of FPT_RCV.2 
Automated recovery is AGD_ADM.1 Administrator guidance (administrator guidance). This assurance 
requirement therefore becomes an assurance requirement for the IT environment. 

The evaluator is reminded that where security requirements for the IT environment refer to the TSF, they refer 
to the security functions of the environment, rather than security functions of the TOE. 

9.3.6.3.10 Work unit ASE_REQ.1 -10 

ISO/IEC 15408-3 ASE_REQ.1.6C: Operations on IT security requirements included in the ST shall be 
identified and performed. 

The evaluator shall check that all operations on IT security requirements are identified. 

The permitted operations for ISO/IEC 15408-2 and ISO/IEC 15408-3 components are assignment, iteration, 
selection and refinement. The assignment and selection operations are permitted only where specifically 
indicated in a component. Iteration and refinement are permitted for all components. 

The evaluator determines that all operations are identified in each component where such an operation is 
used. Identification can be achieved by typographical distinctions, or by explicit identification in the 
surrounding text, or by any other distinctive means. 

9.3.6.3.11 Work unit ASE_REQ.1 -1 1 

The evaluator shall examine the statement of IT security requirements to determine that all assignment and 
selection operations are performed. 
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The evaluator determines that all assignments and selections in all components have either been completely 
performed (there are no choices left to be made in the component) or that is it appropriately justified that is not 
completely performed. 

An example of not completely performing an operation is specifying a range of values when performing the 
assignment operation on the number of concurrent sessions that belong to the same user in FTA_MCS.1 
Basic limitation on multiple concurrent sessions (basic limitation on multiple concurrent sessions). An 
appropriate justification for this is that the value will be selected from the range of values by the administrator 
during TOE installation. 

9.3.6.3.12 Work unit ASE_REQ.1-12 

The evaluator shall examine the ST to determine that all operations are performed correctly. 

The evaluator compares each statement with the element from which it is derived to determine that: 

a) for an assignment, the values of the parameters or variables chosen comply with the indicated type 
required by the assignment; 

b) for a SLelection, the selected item or items are one or more of the items indicated within the selection 
portion of the element. The evaluator also determines that the number of items chosen is appropriate for 
the requirement. Some requirements require a selection of just one item (e.g. FAU_GEN.1.1.b), in other 
cases multiple items (e.g. FDP_ITT.1.1 second operation) are acceptable; 

c) for a refinement, the component is refined in such manner that a TOE meeting the refined requirement 
also meets the unrefined requirement. If the refined requirement exceeds this boundary it is considered to 
be an extended requirement; 

Example: ADV_SPM.1.2C The TSP model shall describe the rules and characteristics of all policies of the 
TSP that can be modelled. Refinement: The TSP model need cover only access control. If the access 
control policy is the only policy of the TSP this is a valid refinement. If there are also identification and 
authentication policies in the TSP, and the refinement is meant to state that only access control needs to 
be modeled, then this is not a valid refinement. 

A special case of refinement is an editorial refinement, where a small change is made in a requirement, 
i.e. rephrasing a sentence due to adherence to proper English grammar. This change is not allowed to 
modify the meaning of the requirement in any way. 

An example of an editorial refinement is FAU_ARP.1 with a single action. Instead of writing; "The TSF 
shall take inform the operator upon detection of a potential security violation"ihe ST author is allowed to 
write: "The TSF shall inform the operator upon detection of a potential security violation". 

The evaluator is reminded that editorial refinements have to be clearly identified (see work unit 
ASE_REQ.1-10). 

d) for an iteration, that each iteration of a component is different from each other iteration of that component 
(at least one element of a component is different from the corresponding element of the other component), 
or that the component applies to a different part of the TOE. 

9.3.6.3.13 Work unit ASE_REQ.1 -13 

ISO/IEC 15408-3 ASE_REQ.1.7C: Dependencies among the IT security requirements included in the ST 
should be satisfied. 

The evaluator shall examine the statement of IT security requirements to determine that dependencies 
required by the components used in the IT security requirements statement are satisfied. 
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Dependencies may be satisfied by the inclusion of the relevant component (or one that is hierarchical to it) 
within the statement of TOE security requirements, or as a requirement that is asserted as being met by the IT 
environment of the TOE. 

Although ISO/IEC 15408 provides support for dependency analysis by inclusion of dependency, this is not a 
justification that no other dependencies exist. An example of such other dependencies is an element that 
refers to "all objects" or "all subjects', where a dependency could exist to a refinement in another element or 
set of elements where the objects or subjects are enumerated. 

Dependencies of security requirements necessary in the IT environment should be stated and satisfied in the 
ST. 

The evaluator is reminded that ISO/IEC 15408 does not require all dependencies to be satisfied: see the 
following work-unit. 

9.3.6.3.14 Work unit ASE_REQ.1 -14 

ISO/IEC 15408-3 ASE_REQ.1.8C: The evidence shall justify why any non-satisfaction of dependencies is 
appropriate. 

The evaluator shall examine the security requirements rationale to determine that an appropriate justification 
is given for each case where security requirement dependencies are not satisfied. 

The evaluator determines that the justification explains why the dependency is unnecessary, given the 
identified security objectives. 

The evaluator confirms that any non-satisfaction of a dependency does not prevent the set of security 
requirements adequately addressing the security objectives. This analysis is addressed by ASE_REQ.1.12C. 

An example of an appropriate justification is when a software TOE has the security objective: "failed 
authentications shall be logged with user identity, time and date" and uses FAU_GEN.1 Audit data generation 
(audit data generation) as a functional requirement to satisfy this security objective. FAU_GEN.1 Audit data 
generation contains a dependency on FPT_STM.1 Reliable time stamps (reliable time stamps). As the TOE 
does not contain a clock mechanism, FPT_STM,1 Reliable time stamps is defined by the ST author as a 
requirement on the IT environment. The ST author indicates that this requirement will not be satisfied with the 
justification: "there are attacks possible on the time-stamping mechanism in this particular environment, the 
environment can therefore not deliver a reliable time-stamp. Yet, some threat agents are incapable of 
executing attacks against the time-stamping mechanisms, and some attacks by these threat agents may be 
analysed by logging time and date of their attacks." 

9.3.6.3.1 5 Work unit ASE_REQ.1 -1 5 

ISO/IEC 15408-3 ASE_REQ.1.9C: The ST shall include a statement of the minimum strength of function level 
for the TOE security functional requirements, either SOF-basic, SOF-medium or SOF-high, as appropriate. 

The evaluator shall check that the ST includes a statement of the minimum strength of function level for the 
TOE security functional requirements, and that this level is either SOF-basic, SOF-medium or SOF-high. 

If the TOE security assurance requirements do not' include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is not applicable and is therefore considered to be satisfied. 

The strength of cryptographic algorithms is outside the scope of ISO/IEC 15408. Strength of function only 
applies to probabilistic or permutational mechanisms that are non-cryptographic. Therefore, where an ST 
contains a minimum SOF claim this claim does not apply to any cryptographic mechanisms with respect to an 
ISO/IEC 15408 evaluation. Where such cryptographic mechanisms are included in a TOE the evaluator 
determines that the ST includes a clear statement that the assessment of algorithmic strength does not form 
part of the evaluation. 



51 



IS 15671 :2006 
ISO/IEC 18045 :2005 

The TOE may contain multiple distinct domains, where the ST writer deems it to be more applicable to have a 
minimum strength of function level for each domain, rather than having one overall minimum strength of 
function level for the entire TOE. In this case it is allowed to partition the TOE security functional requirements 
in distinct sets, and have different minimum strength of function levels associated with each set. 

An example of this is a distributed terminal system which has user terminals that are in a public space, and 
administrator terminals that are in a physically secure place. The authentication requirements for the user 
terminals have SOF-medium associated with them, and the authentication requirements for the administrative 
terminals have SOF-basic associated with them. Rather than stating that the TOE has a minimum strength of 
function level of SOF-basic, which might lead potential consumers of the TOE to believe that it would be 
relatively easy to successfully attack the authentication mechanisms on user terminals, the ST writer divides 
the TOE into a user domain and an administrative domain, partitions the TOE security functional requirements 
into sets belonging to those domains, assigns a minimum strength of function level of SOF-basic to the set 
belonging to the administrative domain, and assigns a minimum strength of function level of SOF-medium to 
the set belonging to the user domain. 

9.3.6.3.16 Work unit ASE_REQ.1-16 

ISO/IEC 15408-3 ASE_REQ.1.10C: The statement of security requirements shall identify all security 
functional requirements for which an explicit strength of function claim is required, together with the explicit 
strength of function claim for each such security functional requirement. 

The evaluator shall check that the ST identifies any specific TOE security functional requirements for which an 
explicit strength of function is appropriate, together with the specific strength of function or metric as 
applicable. 

If the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security ftrction 
evaluation, this work unit is not applicable and is therefore con^dered to be satisfied. 

The explicit strength of function claim can be either SOF-basic, SOF-medium, SOF-high, or a defined specific 
metric. Where a specific metric is used, the evaluator determines that these are appropriate for the type of 
functional requirement specified, and that the metric specified is evaluatable as a strength claim. This work 
unit refers to the case where an ST author requires to set specific SOF requirements (i.e. higher than the 
overall SOF claim of the ST) or by using a metric, A specific SOF claim for a TOE security functional 
requirement may be specified by a PP author. In the absence of any specific claim, the overall claim for the 
ST applies for all TOE security functional requirements stated in the ST. The evaluator should confirm the 
presence or absence of explicit SOF claims is consistent with other parts of the ST. 

An ST could potentially have varying specifications of SOF claims. There can be an overall SOF claim for an 
ST and within an ST the TOE security functional requirements could have a SOF claim specified for it. 

Further guidance on appropriateness and suitability of strength of function metrics may be provided by the 
scheme. 

9.3.6.3.17 Work unit ASE„REQ.1 -17 

ISO/IEC 15408-3 ASE_REQ.1.11C: The security requirements rationale shall demonstrate that the minimum 
strength of function level for the ST together with any explicit strength of function claim is consistent with the 
security objectives for the TOE. 

The evaluator shall examine the security requirements rationale to determine that it demonstrates that the 
minimum strength of function level, together with any explicit strength of function claim, is consistent with the 
security objectives for the TOE. 

if the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is not applicable and is therefore considered to be satisfied. 

The evaluator determines that the rationale takes into account details about the likely expertise, resources, 
and motivation of attackers as described in the statement of TOE security environment. For example, a claim 
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of SOF-basic is inappropriate if the TOE is required to provide defence against attackers who possess a high 
attack potential. 

The evaluator also determines that the rationale takes into account any specific strength-related properties of 
security objectives. The evaluator can use the tracings from requirements to objectives to determine that 
requirements that trace towards objectives with specific strength related properties, if appropriate, have a 
suitable strength of function claim associated with them. 

9.3.6.3.18 Work unit ASE_REQ.1-18 

ISO/lEC 15408-3 ASE_REQ.1 .12C: The security requirements rationale shall demonstrate that the IT security 
requirements are suitable to meet the security objectives. 

The evaluator shall examine the security requirements rationale to determine that the TOE security 
requirements are traced back to the security objectives for the TOE. 

The evaluator determines that each TOE security functional requirement is traced back to at least one security 
objective for the TOE. 

Failure to trace implies that either the security requirements rationale is incomplete, the security objectives are 
incomplete, or that the TOE security functional requirement has no useful purpose. 

It is also allowed, but not marrdatory, for some or all TOE security assurance requirements to trace back to 
security objectives for the TOE. 

An example of a TOE security assurance requirement tracing back to a security objective for the TOE is an ST 
containing the threat "A user unwittingly discloses information by using a device thinking it to be the TOE" and 
the security objective for the TOE "The TOE shall be clearly labelled with its version number" to counter that 
threat. This security objective for the TOE can be achieved by satisfying ACM_CAP.1 Version numbers and 
the ST author therefore traces ACM_CAP.1 Version numbers back to that security objective for the TOE. 

9.3.6.3.19 Work unit ASE_REQ.1 -19 

The evaluator shall examine the security requirements rationale to determine that the security requirements 
for the IT environment are traced back to the security objectives for the environment. 

The evaluator determines that each functional security requirement for the IT environment is traced back to at 
least one security objective for the environment. 

Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for 
the environment are incomplete, or that the functional security requirement for the IT environment has no 
useful purpose. 

It is also allowed, but not mandatory, for some or all security assurance requirements for the IT environment to 
trace back to security objectives for the environment. 

9.3.6.3.20 Work unit ASE_REQ.1 -20 

The evaluator shall examine the security requirements rationale to determine that for each security objective 
for the TOE it contains an appropriate justification that the TOE security requirements are suitable to meet that 
security objective for the TOE. 

If no TOE security requirements trace back to the security objective for the TOE, this work unit fails. 

The evaluator determines that the justification for a security objective for the TOE demonstrates that if all TOE 
security requirements that trace back to the objective are satisfied, the security objective for the TOE is 
achieved. 
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The evaluator also determines that each TOE security requirement that traces back to a security objective for 
the TOE, when satisfied, actually contributes to achieving the security objective. 

Note that the tracings from TOE security requirements to security objectives for the TOE provided in the 
security requirements rationale may be a part of the justification, but do not constitute a justification by 

themselves. 

9.3.6.3.21 Work unit ASE_REQ.t-21 

The evaluator shall examine the security requirements rationale to determine that for each security objective 
for the IT environment it contains an appropriate justification that the security requirements for the IT 
environment are suitable to meet that security objective for the IT environment. 

if no security requirements for the IT environment trace back to the security objective for the IT environment, 
this work unit fails. 

The evaluator determines that the justification for a security objective for the environment demonstrates that if 
all security requirements for the IT environment that trace back to the security objective for the IT environment 
are satisfied, the security objective for the IT environment is achieved. 

The evaluator also determines that each security requirement for the IT environment that traces back to a 
security objective for the IT environment, when satisfied, actually contributes to achieving the security 
objective. 

Note that the tracings from security requirements for the IT environment to security objectives for the IT 
environment provided in the security requirements rationale may be a part of a justification, but do not 
constitute a justification by themselves. 

9.3.6.3.22 Work unit ASE_REQ.1-22 

ISO/IEC 15408-3 ASE_REQ.1.13C: The security requirements rationale stiall demonstrate that the set of IT 
security requirements together forms a mutually supportive and internally consistent whole. 

The evaluator shall examine the security requirements rationale to determine that it demonstrates that the set 
of IT security requirements is internally consistent. 

The evaluator determines that on all occasions where different IT security requirements apply to the same 
types of events, operations, data, tests to be performed etc., and these requirements might conflict, an 
appropriate justification is provided that this is not the case. 

For example, if the ST contains requirements for individual accountability of users as well as requirements for 
user anonymity, it needs to be shown that these requirements do not conflict, this might involve showing that 
none of the auditabte events requiring individual user accountability relate to operations for which user 
anonymity is required. 

For guidance on consistency analysis see A.3, Consistency analysis. 

9.3.6.3.23 Work unit ASE_REQ.1 -23 

The evaluator shall examine the security requirements rationale to determine that it demonstrates that the set 
of IT security requirements together forms a mutually supportive whole. 

This work unit builds on the determination performed in work units ASE_REQ.1-18 and ASE_REQ.1-19 , 
which examine the tracing from IT security requirements to security objectives and work units ASE_REQ.1-20 
and ASE_REQ.1-21 which examine whether the IT security requirements are suitable to meet the security 
objectives. This work unit requires the evaluator to consider the possibility that a security objective might in 
fact not be achieved because of lack o^ support from other IT security requirements. 
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This work unit also builds on the dependency analysis addressed by previous work units, because If functional 
requirement A has a dependency on functional requirement B, B supports A by definition. 

The evaluator determines that the security requirements rationale demonstrates that functional requirements 
support each other where necessary, even when no dependency between these requirements is indicated. 
This demonstration should address security functional requirements that: 

a) prevent bypass of other security functional requirements, such as FPT_RVM.1 Non-bypassability of the 
TSP; 

b) prevent tampering with other security functional requirements, such as Domain separation (FPT_SEP); 

c) prevent de-activation of other security functional requirements, such as FMT_MOF.1 Management of 
security functions behaviour; 

d) enable detection of attacks aimed at defeating other security functional requirements, such as 
components of the FAU: Security audit class. 

The evaluator takes the performed operations into account in his analysis to determine whether they affect the 
mutual support between the requirements. 

9.3.6.4 Action ASE_REQ.1.2E 

9.3.6.4.1 Work unit ASE_REQ.1 -24 

The evaluator shall examine the statement of IT security requirements to determine that it is coherent. 

The statement of IT security requirements is coherent if the text and structure of the statement are 
understandable by its target audience (i.e. evaluators and consumers). 

9.3.6.4.2 Work unit ASE_REQ.1-25 

The evaluator shall examine the statement of IT security requirements to determine that it is complete. 

This work unit draws on the results from the work units required by ASE_REQ.1.1E and ASE_SRE.1.1E, and 
in particular the evaluator's examination of the security requirements rationale. 

The statement of security requirements is complete if all operations on requirements have been completed, 
and the evaluator judges the security requirements to be sufficient to ensure that all security objectives for the 
TOE are satisfied. 

9.3.6.4.3 Work unit ASE_REQ.1 -26 

The evaluator shall examine the statement of IT security requirements to determine that it is internally 
consistent. 

This work unit draws on the results from the work units required by ASE_REQ.1.1E and ASE_SRE.1.1E. and 
in particular the evaluator's examination of the security requirements rationale. 

The statement of security requirements is internally consistent if the evaluator determines that no security 
requirement conflicts with any other security requirement, such that a security objective will not be fully 
satisfied. 

For guidance on consistency analysis see A. 3, Consistency analysis. 
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9.3.7 Evaluation of Explicitly stated IT security requirements (ASE_SRE.1) 

9.3.7.1 Objectives 

The objective of this sub-activity is to determine whether the security functional requirements or security 
assurance requirements that are stated without reference to ISO/IEC 15408 are appropriate and adequate. 

9.3.7.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.7.3 Application notes 

This subclause is only applicable if the ST contains IT security requirements that are explicitly stated without 
reference to either ISO/IEC 15408-2 or ISO/IEC 15408-3. If this Is not the case, all work units In this subclause 
are not applicable, and therefore considered to be satisfied. 

The Explicitly stated IT security requirements (ASE_SRE) requirements do not replace the IT security 
requirements (ASE_REQ) requirements, but are additional to them. This means that IT security requirements 
that are explicitly stated without reference to either ISO/IEC 15408-2 or ISO/IEC 15408-3 must be evaluated 
with the Explicitly stated IT security requirements (ASE_SRE) criteria, and also, in combination with ail other 
security requirements, with the IT security requirements {ASE_REQ) criteria. 

9.3.7.4 Action ASE_SRE.1.1E 

9.3.7.4.1 Work unit ASE_SRE.1 -1 

ISO/IEC 15408-3 ASE_SRE.1 .10: All TOE security requirements that are explicitly stated without reference to 
ISO/IEC 15408 shall be identified. 

The evaluator shall check that the statement of the IT security requirements identifies all TOE security 
requirements that are explicitly stated without reference to ISO/IEC 15408. 

Any TOE security functional requirements that are not specified using ISO/IEC 15408-2 functional 
components are required to be clearly identified as such. Similarly, any TOE security assurance requirements 
that are not specified using ISO/IEC 15408-3 assurance components are also required to be clearly identified 
as such. 

9.3.7.4.2 Work unit ASE_SRE.1-2 

ISO/IEC 15408-3 ASE_SRE.1.2C: All security requirements for the IT environment that are explicitly stated 
without reference to ISO/IEC 15408 shall be identified. 

The evaluator shall check that the statement of IT security requirements identifies all security requirements for 
the IT environment that are explicitly stated without reference to ISO/lEC 15408. 

Any security functional requirements for the IT environment that are not specified using ISO/IEC 15408-2 
functional components are required to be clearly identified as such. Similarly, any security assurance 
requirements for the IT environment that are not specified using ISO/IEC 15408-3 assurance components are 
also required to be clearly identified as such. 

9.3.7.4.3 Work unit ASE_SRE.1 -3 

ISO/IEC 15408-3 ASE_SRE.1 .30: The evidence shall justify why the security requirements had to be explicitly 
stated. 
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The evaluator shall examine the security requirements rationale to determine that it appropriately justifies why 
each explicitly stated IT security requirement had to be explicitly stated. 

The evaluator determines for each explicitly stated IT security requirement that the justification explains why 
existing functional or assurance components (from ISO/IEC 15408-2 and ISO/IEC 15408-3, respectively) 
could not be used to express the explicitly stated security requirement in question. The evaluator takes the 
possibility of performing operations (i.e. assignment, iteration, selection or refinement) on these existing 
components into account in this determination. 

9.3.7.4.4 Work unit ASE_SRE.1 -4 

ISO/^EC 15408-3 ASE_SRE.1.4C: The explicitly stated IT security requirements stiall use ISO/IEC 15408 
requirements components, families and classes as a model for presentation. 

The evaluator shall examine each explicitly stated IT security requirement to determine that the requirement 
uses ISO/IEC 15408 requirements components, families and classes as a model for presentation. 

The evaluator determines that explicitly stated IT security requirements are presented in the same style as 
ISO/IEC 15408-2 or ISO/IEC 15408-3 components and to a comparable level of detail. The evaluator also 
determines that the functional requirements are broken down into individual functional elements and that the 
assurance requirements specify the developer action, content and presentation of evidence, and evaluator 
action elements. 

9.3.7.4.5 WorkunitASE_SRE.1-5 

ISO/IEC 15408-3 ASE_SRE.1.5C: Tfie explicitly stated IT security requirements stiall be measurable and 
state objective evaluation requirements suet) that compliance or noncompliance of a TOE can be determined 
and systematically demonstrated. 

The evaluator shall examine each explicitly stated IT security requirement to determine that it is measurable 
and states objective evaluation requirements, such that compliance or noncompliance of a TOE can be 
determined and systematically demonstrated. 

The evaluator determines that functional requirements are stated in such a way that they are testable, and 
traceable through the appropriate TSF representations. The evaluator also determines that assurance 
requirements avoid the need for subjective evaluator judgement. 

The existing ISO/IEC 15408 functional and assurance requirements are to be used as models for compliance 
with this requirement. 

9.3.7.4.6 Work unit ASE_SRE.1 -6 

ISO/IEC 15408-3 ASE_SRE.1.6C: The explicitly stated IT security requirements shall be clearly and 
unambiguously expressed. 

The evaluator shall examine each explicitly stated IT security requirement to determine that it is clearly and 
unambiguously expressed. 

The existing ISO/IEC 15408 functional and assurance requirements are to be used as models for compliance 
with this requirement. 

9.3.7.4.7 Work unit ASE_SRE.1 -7 

ISO/IEC 15408-3 ASE_SRE.1.7C: The security requirements rationale shall demonstrate that the assurance 
requirements are applicable and appropriate to support any explicitly stated TOE security functional 
requirements. 
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The evaluator shall examine the security requirements rationale to determine that it demonstrates that the 
assurance requirements are applicable and appropriate to support any explicitly stated TOE security 
functional requirements. 

The evaluator determines whether application of the specified assurance requirements will yield a meaningful 
evaluation result for each explicitly stated security functional requirement, or whether other assurance 
requirements should have been specified. For example, an explicitly stated functional requirement may imply 
the need for particular documentary evidence (such as a TSP model), depth of testing, or analysis (such as 
strength of TOE security functions analysis or covert channel analysis). 

9.3.7.5 Action ASE_SRE.1.2E 

9.3.7.6.1 WorkunitASE_SRE.1-8 

The evaluator shall examine tKe statement of IT seojrity requirements to determine that all of the 
dependencies of any explicitly stated IT security requirement have been identified. 

The evaluator confirms that no applicable dependencies have been overlooked by the ST author. 

Examples of possible dependencies are: components of the FAU: Security audit class if an explicitly stated 
functional requirement mentions auditing and Implementation representation (ADV_IMP) if an explicitly stated 
assurance requirement mentions the source code or implementation representation of the TOE. 

9.3.8 Evaluation of TOE summary specification (ASE_TSS.1) 

9.3.8.1 Objectives 

The objective of this sub-activity is to determine whether the TOE summary specification provides a clear and 
consistent high-level definition of the security functions and assurance measures, and that these satisfy the 
specified TOE security requirements. 

9.3.8.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST. 

9.3.8.3 Action ASE_TSS.1. IE 

9.3.8.3.1 Work unit ASE_TSS.1-1 

ISO/IEC 15408-3 ASE_TSS.1 .1 C: The TOE summary specification shall describe the IT security functions and 
the assurance measures of the TOE. 

The evaluator shall check that the TOE summary specification describes the IT security functions and 
assurance measures of the TOE. 

The evaluator determines that the TOE summary specification provides a high-level definition of the security 
functions claimed to meet the TOE security functional requirements, and of the assurance measures claimed 
to meet the TOE security assurance requirements. 

The assurance measures can be explicitly stated, or defined by reference to the documents that satisfy the 
security assurance requirements (e.g. relevant quality plans, life cycle plans, management plans). 

9.3.8.3.2 WorkunitASE_TSS.1-2 

ISO/lEC 15408-3 ASE_TSS.1 .20: The TOE summary specification shall trace the IT security functions to the 
TOE security functional requirements such that it can be seen which IT security functions satisfy which TOE 
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security functional requirements and tt\at every IT security function contributes to the satisfaction of at least 
one TOE security functional requirement. 

The evaluator shall check the TOE summary specification to determine that each IT security function is traced 
to at least one TOE security functional requirement. 

Failure to trace implies that either the TOE summary specification is Incomplete, the TOE security functional 
requirements are incomplete, or the IT security function has no useful purpose. 

9.3.8.3.3 Work unit ASE_TSS.1 -3 

ISO/IEC 15408-3 ASE_TSS.1.3C: The IT security functions shall be defined in an informal style to a level of 
detail necessary for understanding their intent. 

The evaluator shall examine each IT security function to determine that it is described in an informal style to a 
level of detail necessary for understanding its intent. 

In some cases, an IT security function may provide no more detail than is provided in the corresponding TOE 
security functional requirement or requirements. In others, the ST author may have included TOE-specific 
details, for example using TOE-specific terminology in place of generic terms such as "security attribute". 

Note that a semi-formal or formal style of describing IT security functions is not allowed here, unless 
accompanied by an informal style description of the same^unctions. The goal here is to understand the tntent 
of the function, rather than determining properties such as completeness or correctness of the functions. 

9.3.8.3.4 Work unit ASE_TSS.1 -4 

ISO/IEC 1 5408-3 ASE_TSS. 1 .4C: All references to security mechanisms included in the ST shall be traced to 
the relevant security functions so that it can be seen which security mechanisms are used in the 
implementation of each function. 

The evaluator shall examine the TOE summary specification to determine that all references to security 
mechanisms in the ST are traced back to IT security functions. 

References to security mechanisms are optional in an ST but may {for example) be appropriate where there is 
a requirement to implement particular protocols or algorithms (e.g. specified password generation or 
encryption algorithms). If the ST contains no references to security mechanisms, this work unit is not 
applicable and is therefore considered to be satisfied. 

The evaluator determines that each security mechanism that the ST refers to Is traced back to at least one IT 
security function. 

Failure to trace implies that either the TOE summary specification is inwimplete or the security mechanism 
has no useful purpose. 

9.3.8.3.5 Work unit ASE_TSS.1 -5 

ISO/IEC 15408-3 ASE_TSS.1 .5C: The TOE summary specification rationale shall demonstrate that the IT 
security functions are suitable to meet the TOE security functional requirements. 

The evaluator shall examine the TOE summary specification rationale to determine that for each TOE security 
functional requirement it contains an appropriate justification that the IT security functions are suitable to meet 
that TOE security functional requirement. 

If no IT security functions trace back to the TOE security functional requirement, this work unit fails. 

The evaluator determines that the justification for a TOE security functional requirement demonstrates that if 
all IT security functions that trace back to that requirement are implemented, the TOE security functional 
requirement is met. 
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The evaluator also determines that each IT security function that traces back to a TOE security functional 
requirement, when implemented, actually contributes to meeting that requirement. 

Note that the tracings from IT security functions to TOE security functional requirements provided in the TOE 
summary specification may be a part of a justification, but do not constitute a justification by themselves. 

9.3.8.3.6 Work unit ASE_TSS.1-6 

The evaluator shall examine the TOE summary specification rationale to determine that the strength of 
function claims for the IT security functions are consistent with the strength of functions for the TOE security 
functional requirements. 

This work unit draws on the results of the ASE_TSS.1-10 work unit. 

The evaluator determines that for each IT security function for which a strength of function claim is appropriate, 
the TOE summary specification rationale demonstrates that this claim is adequate for all TOE security 
functional requirements that it traces back to. 

Usually adequacy means that the strength of function claim of the IT security function is equal to or higher 
than the strength of function of all TOE security functional requirements that it traces to, but exceptions are 
possible. An example of such an exception is the case where multiple low strength functions are used 
sequentially to implement a medium strength authentication requirement for authentication (e.g. biometry and 
a PIN). 

9.3.8.3.7 Work unit ASE_TSS.1-7 

ISO/IEC 15408-3 ASE_TSS.1.6C: The TOE summary specification rationale stiali demonstrate that the 
combination of the specified IT security functions work together so as to satisfy the TOE security functional 
requirements. 

The evaluator shall examine the TOE summary specification rationale to determine that it demonstrates that 
the combination of the specified IT security functions work together so as to satisfy the TOE security functional 
requirements. 

This work unit builds on the determination of mutual support performed on the TOE security functional 
requirements in work unit ASE_REQ.1-23. The evaluator's analysis here should assess the impact of 
additional information included in the IT security functions to determine that the inclusion of such information 
introduces no potential security weaknesses, such as possibilities to bypass, tamper with, or deactivate other 
IT security functions. 

9.3.8.3.8 Work unit ASE_TSS.1-8 

ISO/IEC 15408-3 ASE_TSS.1 .7C: The TOE summary specification shall trace the assurance measures to the 
assurance requirements so that it can be seen which measures contribute to the satisfaction of which 
requirements. 

The evaluator shall check the TOE summary specification to determine that each assurance measure is 
traced to at least one TOE security assurance requirement. 

Failure to trace implies that either the TOE summary specification or the statement of TOE security assurance 
requirements is incomplete, or that the assurance measure has no useful purpose. 

9.3.8.3.9 WorkunltASE_TSS.1-9 

ISO/IEC 15408-3 ASE_TSS.1.8C/' Trte TOE summary specification rationale shall demonstrate that the 
assurance measures meet all assurance requirements of the TOE. 
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The evaluator shall examine the TOE summary specification rationale to determine that for each TOE security 
assurance requirement it contains an appropriate justification that the assurance measures meet that TOE 
security assurance requirement. 

If no assurance measures trace back to the TOE security assurance requirement, this work unit fails. 

The evaluator determines that the justification for a TOE security assurance requirement demonstrates that If 
all assurance measures that trace back to that requirement are implemented, the TOE security assurance 
requirement is met. 

The evaluator also determines that each assurance measure that traces back to a TOE security assurance 
requirement, when implemented, actually contributes to meeting that requirement. 

An assurance measure describes how the developer will address the assurance requirements. The aim of this 
work unit is to determine that the specified assurance measures are appropriate to satisfy the assurance 
requirements. 

Note that the tracings from assurance measures to TOE security assurance requirements provided in the TOE 
summary specification may be a part of a justification, but do not constitute a justification by themselves. 

9.3.8.3.10 Work unit ASE_TSS.1-10 

I SO/I EC 15408-3 ASE_TSS.1.9C: The TOE summary specification sliall identify all IT security functions that 
are realised by a probabilistic or permutational mechanism, as appropriate. 

The evaluator shall check that the TOE summary specification identifies all IT security functions that are 
realised by a probabilistic or permutational mechanisms. 

If the TOE security assurance requirements do not include AVA_S0F.1, this work unit is not applicable and is 
therefore considered to be satisfied. 

This work unit might be revisited after analysis of other evaluation evidence identifies permutational or 
probabilistic mechanisms that are not identified as such in the ST. 

9.3.8.3.11 Work unit ASE_TSS.1 -11 

ISO/IEC 15408-3 ASE_TSS.1.10C: 777© TOE summary specification shall, for each IT security function for 
which it is appropriate, state the stren0h of function claim either as a specific metric, or as SOF-basic, SOF- 
medium or SOF-high. 

The evaluator shall check that, for each IT security function for which it is appropriate, the TOE summary 
specification states the strength of function claim either as a specific metric or as SOF-basic, SOF-medium or 

SOF-high. 

If the TOE security assurance requirements do not include AVA_S0F.1 Strength of TOE security function 
evaluation, this work unit is not applicable and is therefore considered to be satisfied. 

9.3.8.4 Action ASE_TSS.1.2E 

9.3.8.4.1 Work unit ASE_TSS.1-12 

The evaluator shall examine the TOE summary specification to determine that it is complete. 

The TOE summary specification is complete if the evaluator judges the IT security functions and assurance 
measures to be sufficient to ensure that all specified TOE security requirements are satisfied. This work unit 
should be performed in conjunction with the ASE_TSS.1-5 and ASE_TSS.1-9 work units. 
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9.3.8.4.2 Work unit ASE_TSS.1 -13 

The evaluator shall examine the TOE summary specification to determine that it is coherent. 

The TOE summary specification is coherent if its text and structure are understandable by its target audience 
(i.e. evaluators and developers). 

9.3.8.4.3 Work unit A$E_TSS.1 -14 

The evaluator shall examine the TOE summary specification to determine that it is internally consistent. 

The TOE summary specification is internally consistent if the evaluator determines there is no conflict between 
IT security functions or assurance measures, such that a security requirement for the TOE will not be fully 
satisfied. 

For guidance on consistency analysis see A.3, Consistency analysis. 
10 EAL1 evaluation 

10.1 introduction 

EAL1 provides a basic level of assurance. The security functions are analysed using a functional specification 
and guidance documentation to understand the security behaviour. Independent testing of a subset of the 
TOE security functions is performed. 

10.2 Objectives 

The objective of this clause is to define the minimal evaluation effort for achieving an EAL1 evaluation and to 
provide guidance on ways and means of accomplishing the evaluation. 

10.3 EAL1 evaluation relationships 

An EAL1 evaluation covers the following; 

a) evaluation input task (Clause 7); 

b) EAL1 evaluation activities comprising the following: 

1) evaluation of the ST (Clause 9); 

2) evaluation of the configuration management (Subclause 10.4); 

3) evaluation of the delivery and operation documents (Subclause 10.5); 

4) evaluationofthedevelopment documents (Subclause 10.6); 

5) evaluation of the guidance documents (Subclause 10.7); 

6) testing (Subclause 10.8); 

c) evaluation output task (Clause 7). 

The evaluation activities are derived from the EAL1 assurance requirements contained in ISO/lEC 15408-3. 

The ST evaluation is started priot' to any TOE evaluation sub-activities since the ST provides the basis and 
context to perform these sub-activities. 
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The sub-activities comprising an EAL1 evaluation are described in this clause. Although the sub-activities can. 
in general, be started more or less coincidentally, some dependencies between sub-activities have to be 
considered by the evaluator. 

For guidance on dependencies see Annex A 

10.4 Configuration management activity 

The purpose of the configuration management activity is to assist the consumer in identifying the evaluated 
TOE. 

10.4.1 Evaluation of CM capabilities (ACIVI_CAP.1) 

10.4.1.1 Objectives 

The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE. 

10.4.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the TOE suitable for testing. 

10.4.1.3 Action ACM„CAP.1.1E 

10.4.1.3.1 Work unit 1:ACM_CAP.1-1 

ISO/IEC 15408-3 ACM_CAP.1.1C: The reference for the TOE shall be unique to each version of the TOE. 

The evaluator shall check that the version of the TOE provided for evaluation is uniquely referenced. 

For this assurance component there is no requirement for the developer to use a CM system, beyond unique 
referencing. As a result the evaluator is able to verify the uniqueness of a TOE version only by checking that 
other versions of the TOE available for purchase do not possess the same reference. In evaluations where a 
CM system was provided in excess of ISO/IEC 15408 requirements, the evaluator could validate the 
uniqueness of the reference by checking the configuration list. Evidence that the version provided for 
evaluation is uniquely referenced may be incomplete if only one version is examined during the evaluation, 
and the evaluator should look for a referencing system that is capable of supporting unique references (e.g. 
use of numbers, letters or dates). However, the absence of any reference will normally lead to a fail verdict 
against this requirement unless the evaluator is confident that the TOE can be uniquely identified. 

The evaluator should seek to examine more than one version of the TOE (e.g. during rework following 
discovery of a vulnerability), to check that the two versions are referenced differently. 

10.4.1.3.2 Workunit1:ACM_CAP.1-2 

ISO/IEC 1 5408-3 ACM_CAP.1 .20: The TOE shall be labelled with its reference. 

The evaluator shall check that the TOE provided for evaluation is labelled with its reference. 

The evaluator should ensure that the TOE contains a unique reference such that it is possible to distinguish 
different versions of the TOE. This could be achieved through labelled packaging or media, or by a label 
displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the 
TOE (e.g. at the point of purchase or use). 
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The TOE may provide a method by which It can be easily identified. For example, a software TOE may display 
its name and version number during the start up routine, or in response to a command line entry. A hardware 
or firmware TOE may be identified by a part number physically stamped on the TOE. 

10.4.1.3.3 Work unit 1:ACM_CAP.1-3 

The evaluator shall check that the TOE references used are consistent. 

If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible 
to relate any labelled guidance documentation supplied as part of the TOE to the evafuated operational TOE. 
This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, 
that they have installed this version, and that they have the correct version of the guidance to operate the TOE 
in accordance with its ST. 

The evaluator also verifies that the TOE reference is consistent with the ST. 

For guidance on consistency analysis see A.3, Consistency analysis. 

10.5 Delivery and operation activity 

The purpose of the delivery and operation activity is to judge the adequacy of the documentation of the 
procedures used to ensure that the TOE is installed, generated, and started in the same way the developer 
intended it to be. 

10.5.1 Evaluation of Installation, generation and start-up (ADOJGS.I) 

10.5.1.1 Objectives 

The objective of this sub-activity is to determine whether the procedures and steps for the secure Installation, 
generation, and start-up of the TOE have been documented and result in a secure configuration. 

10.5.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the administrator guidance; 

b) the secure installation, generation, and start-up procedures; 

c) the TOE suitable for testing. 

10.5.1.3 Application notes 

The installation, generation, and start-up procedures refer to all installation, generation, and start-up 
procedures, regardless of whether they are performed at the user's site or at the development site that are 
necessary to progress the TOE to the secure configuration as described in the ST. 

10.5.1.4 Action AD0JGS.1. IE 

10.5.1.4.1 Work unit 1:AD0JGS.1-1 

ISO/IEC 15408-3 ADOJGS.I. 1C: The installation, generation and start-up documentation shall describe all 
the steps necessary for secure installation, generation and start-up of the TOE. 

The evaluator shall check that the procedures necessary for the secure installation, generation and start-up of 
the TOE have been provided. 
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If it is not anticipated thiat the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, ^nd is therefore considered to be satisfied. 

10.5.1.5 Action ADO JGS.1.2E 

10.5.1.5.1 Work unit 1:AD0_IGS.1-2 

The evaluator shall examine the provided installation, generation, and start-up procedures to determine that 
they describe the steps necessary for secure installation, generation, and start-up of the TOE, 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

The installation, generation, and start-up procedures may provide detailed information about the following: 

a) changing the installation specific security characteristics of entities under the control of the TSF; 

b) handling exceptions and problems; 

c) minimum system requirements for secure installation if applicable. 

In order to confirm that the installation, generation, and start-up procedures result in a secure configuration, 
the evaluator may follow the developer's procedures and may perform the activities that customers are usually 
expected to perform to install, generate, and start-up the TOE (if applicable to the TOE), using the supplied 
guidance documentation only. This work unit might be performed in conjunction with the ATEJND.1-2 work 
unit. 

10.6 Development activity 

The purpose of the development activity is to assess the design documentation in terms of its adequacy to 
understand how the TSF provides the security functions of the TOE. This understanding is achieved through 
examination of a functional specification (which describes the external interfaces of the TOE) and a 
representation correspondence (which maps the functional specification to TOE summary specification in 
order to ensure consistency). 

10.6.1 Application notes 

ISO/IEC 15408 requirements for design documentation are levelled by formality. ISO/IEC 15408 considers a 
document's degree of formality (that is, whether it is informal, semiformal or formal) to be hierarchical. An 
informal document is one that is expressed in a natural language. The methodology does not dictate the 
specific language that must be used; that issue is left for the scheme. The following paragraphs differentiate 
the contents of the different informal documents. 

An informal functional specification comprises a description the security functions (at a level similar to that of 
the TOE summary specification) and a description of the externally-visible interfaces to the TSF. For example, 
if an operating system presents the user with a means of self-identification, of creating files, of modifying or 
deleting files, of setting permissions defining what other users may access files, and of communicating with 
remote machines, its functional specification would contain descriptions of each of these functions. If there are 
also audit functions that detect and record the occurrences of such events, descriptions of these audit 
functions would also be expected to be part of the functional specification; while these functions are 
technically not directly invoked by the user at the external interface, they certainly are affected by what occurs 
at the user's external interface. 

Informality of the demonstration of correspondence need not be in a prose form; a simple two-dimensional 
mapping may be sufficient. For example, a matrix with modules listed along one axis and subsystems listed 
along the other, with the cells identifying the correspondence of the two, would serve to provide an adequate 
informal correspondence between the high-level design and the low-level design 
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10.6.2 Evaluation of Functional specification (ADV_FSP.1) 

10.6.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has provided an adequate description 
of the security functions of the TOE and whether the security functions provided by the TOE are sufficient to 
satisfy the security functional requirements of the ST. 

10.6.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance. 

1 0.6.2.3 Action ADV_FSP.1 .1 E 

10.6.2.3.1 Work unit 1:ADV_FSP.1-1 

ISO/IEC 15408-3 ADV_FSP.1.1C: The functional specification shall descritie the TSF and its external 
interfaces using an infonnal style. 

The evaluator shall examine the functional specification to determine that it contains all necessary infonnal 
explanatory text. 

If the entire functional specification is informal, this work unit is not applicable and is therefore considered to 
be satisfied. 

Supporting narrative descriptions are necessary for those portions of the functional specification thjat are 
difficult to understand only from the semiformal or formal description (for example, to make clear the meaning 
of any formal notation). 

10.6.2.3.2 Work unit 1:ADV_FSP.i-2 

ISO/IEC 15408-3 ADV_FSP.1 .20: The functional specificaVon shall be internally consistent. 

The evaluator shall examine the functional specification to determine that it is internally consistent. 

The evaluator validates the functional specification by ensuring that the descriptions of the interfaces making 
up the TSFI are consistent with the descriptions of the functions of the TSF 

^0.6.2.3.3 Workunit1:ADV_FSP.1-3 

ISO/IEC 15408-3 ADV_FSP.1.3C: The functional specification shall describe the purpose and method of use 
of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. 

The evaluator shall examine the functional specification to determine that it identifies all of the external TOE 
security function interfaces. 

The term external refers to that which is visible to the user. External interfaces to the TOE are either direct 
interfaces to the TSF or interfaces to non-TSF portions of the TOE. However, these non-TSF interfaces might 
have eventual access to the TSF. These external interfaces that directly or indirectly access the TSF 
collectively make up the TOE security function interface (TSFI). Figure 6 shows a TOE with TSF (cross- 
hatched) portions and non-TSF (empty) portions. This TOE has three external interfaces: interface c is a direct 
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interface to the TSF; interface b is an indirect interface to the TSF; and interface a is an interface to non-TSF 
portions of the TOE. Therefore, interfaces b and c mal^e up the TFSI. 




TOE 



Figure 6 - TSF Interfaces 

U should be noted that all security functions reflected in the functional requirements of ISO/IEC 15408-2 (or in 
extended components thereoO will have some sort of externally-visibte manifestation. While not all of these 
are necessarily interfaces from which the security function can be tested, they are all externally-visible to 
some extent and must therefore be included in the functional specification. 

10.6.2.3.4 Workunlt1:ADV„FSP.1-4 

The evaluator shall examine the functional specification to determine that it describes all of the external TOE 
security function interfaces. 

For a TOE that has no threat of malicious users {i.e. TSF physical protection (FPT_PHP), Reference 
mediation (FPT_RVM), and Domain separation (FPT_SEP) are rightfully excluded from its ST), the only 
interfaces that are described in the functional specification (and expanded upon in the other TSF 
representation descriptions) are those to and from the TSF. The absence of TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) presumes there is no 
concern for any sort of bypassing of the security features; therefore, there is no concern with any possible 
impact that other interfaces might have on the TSF. 

On the other hand, if the TOE has a threat of malicious users or bypass (i.e. TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) are included in its ST), all 
external interfaces are described in the functional specification, but only to the extent that the effect of each is 
made clear: interfaces to the security functions (i.e. interfaces b and c in Figure 6) are completely described, 
while other interfaces are described only to the extent that it is clear that the TSF is inaccessible through the 
interface (i.e. that the interface is of type a, rather than b in Figure 6). The inclusion of TSF physical protection 
(FPT_PHP). Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) implies a concern that all 
interfaces might have some effect upon the TSF. Because each external interface is a potential TSF interface, 
the functional specification must contain a description of each interface in sufficient detail so that an evaluator 
can determine whether the interface is security relevant. 

Some architectures lend themselves to readily provide this interface description in sufficient detail for groups 
of extemal interfaces. For example, a kernel architecture is such that all calls to the operating system are 
handled by kernel programs; any calls that might violate the TSP must be called by a program with the 
privilege to do so. All programs that execute with privilege must be included in the functional specification. Any 
program external to the kernel that executes without privilege is incapable of affecting the TSP (i.e. such 
programs are interfaces of type a, rather than b in Figure 6) and may, therefore, be excluded from the 
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functional specification. It is worth noting that, while the evaluator's understanding of the interface description 
can be expedited in cases where there is a kernel architecture, such an architecture is not necessary. 

10.6.2.3.5 Work unit 1:ADV_FSP.1-5 

The evaluator shall examine the presentation of the TSFI to determine that it adequately and correctly 
describes the behaviour of the TOE at each external interface describing effects, exceptions and error 
messages. 

In order to assess the adequacy and correctness of an interface's presentation, the evaluator uses the 
functional specification, the TOE summary specification of the ST, and the user and administrator guidance to 
assess the following factors: 

a) All security relevant user Input parameters (or a characterisation of those parameters) should be identified. 
For completeness, parameters outside of direct user control should be identified if they are usable by 
administrators. 

b) All security relevant behaviour described in the reviewed guidance should be reflected in the description 
of semantics in the functional specification. This should include an identification of the behaviour in terms 
of events and the effect of each event. For example, if an operating system provides a rich file system 
interface, where it provides a different error code for each reason why a file is not opened upon request 
(e.g. access denied, no such file, file is in use by another user, user is not authorised to open the file after 
5pm, etc.), the functional specification should explain that a file is either opened upon request, or else that 
an error code is returned. (While the functional specification may enumerate all these different reasons for 
errors, it need not provide such detail.) The description of the semantics should include how the security 
requirements apply to the interface (e.g. whether the use of the interface is an auditable event and, if so, 
the information that can be recorded). 

c) All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, 
the descripfion of the interface should explain how the interface behaves in the presence or absence of 
privilege. 

d) The information contained in the descriptions of the security relevant parameters and syntax of the 
interface should be consistent across all documentation. 

Verification of the above is done by reviewing the functional specification and the TOE summary specification 
of the ST, as well as the user and administrator guidance provided by the developer. For example, if the TOE 
were an operating system and its underlying hardware, the evaluator would look for discussions of user- 
accessible programs, descriptions of protocols used to direct the activities of programs, descriptions of user- 
accessible databases used to direct the acfivities of programs, and for user interfaces (e.g. commands, 
application program interfaces) as applicable to the TOE under evaluation; the evaluator would also ensure 
that the processor instruction set is described. 

This review might be iterative, such that the evaluator would not discover the functional specification to be 
incomplete until the design, source code, or other evidence is examined and found to contain parameters or 
error messages that have been omitted from the functional specification. 

10.6.2.3.6 Work unit 1:ADV_FSP.1-6 

ISO/IEC 15408-3 AD\/_FSP.1 .40: The functional specification siiall completely represent the TSF. 

The evaluator shall examine the functional specification to determine that the TSF is fully represented. 

In order to assess the completeness of the TSF representation, the evaluator consults the TOE summary 
specification of the ST, the user guidance, and the administrator guidance. None of these should describe 
security functions that are absent from the TSF presentation of the functional specification. 
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10.6.2.4 Action ADV_FSP.1.2E 

10.6.2.4.1 Work unit 1:ADV_FSP.1-7 

The evaluator shall examine the functional specification to determine that it is a complete instantiation of the 
TOE security functional requirements. 

To ensure that alt ST security functional requirements are covered by the functional specification, the 
evaluator may construct a map between the TOE summary specification and the functional specification. Such 
a map might be already provided by the developer as evidence for meeting the correspondence 
(Representation correspondence (ADV_RCR).*) requirements, in w/hich case the evaluator need only verify 
the completeness of this mapping, ensuring that all security functional requirements are mapped onto 
applicable TSFI presentations in the functional specification. 

10.6.2.4.2 Work unit 1 :ADV_FSP.1-8 

The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the 
TOE security functional requirements. 

For each interface to a security function with specific characteristics, the detailed information in the functional 
specification must be exactly as it is specified in the ST. For example, if the ST contains user authentication 
requirements that the password length must be eight characters, the TOE must have eight-character 
passwords; if the functional specification describes six-character fixed length passwords, the functional 
specification would not be an accurate instantiation of the requirements. 

For each interface in the functional jspecification that operates on a controlled resource, the evaluator 
determines whether it returns an error code that indicates a possible failure due to enforcement of one of the 
security requirements; if no error code is returned, the evaluator determines whether an error code should be 
returned. For example, an operating system might present an interface to OPEN a controlled object. The 
description of this interface may include an error code that indicates that access was not authorised to the 
object. If such an error code does not exist, the evaluator should confirm that this is appropriate (because, 
perhaps, access mediation is performed on READs and WRITEs, rather than on OPENs). 

10.6.3 Evaluation of Representation correspondence (ADV_RCR.1) 

10.6.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer has correctly and completely 
implemented the requirements of the ST in the functional specification. 

10.6.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the correspondence analysis between the TOE summary specification and the functional specification; 

10.6.3.3 Action ADV_RCR.1 .1 E 

10.6.3.3.1 Work unit 1:ADV_RCR.1-1 

ISO/IEC 15408-3 ADV_RCR.1.1C: For each azijacent pair of provided TSF representations, the analysis shall 
demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and 
completely refmed in the less abstract TSF representation. 
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The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this worl< unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this worl< unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

10.6.3.3.2 Work unit 1: ADV_RCR.1 -2 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

tO.6.3.3.3 Workunit1:ADV_RCR.1-3 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the furrctional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

10.6.3.3.4 Work unit 1:ADV_RCR.1-4 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 
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The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.2-8 and ADV_FSP.2-9. 

1 0.6.3.3.5 Work unit 1 :ADV_RCR.1 -5 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

10.6.3.3.6 Workunit1:ADV_RCR.1-6 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysts, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

10.6.3.3.7 Work unit 1 :ADV„RCR.1-7 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

10.6.3.3.8 Workunit1:ADV_RCR.1-8 

The evaluator shall examine the correspondence analysis between the high-level design and the low-level 
design to determine that the low-level design is a correct and complete representation of the high-level design. 

The evaluator uses the correspondence analysis, the high-level design, and the low-level design to ensure 
that it is possible to map each TSF module identified in the low-level design onto a TSF subsystem described 
in the high-level design. For each TOE security function, the correspondence indicates which. TSF modules 
are involved in the support of the function. The evaluator verifies that the low-level design includes a 
description of a correct realisation of each security function. 
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10.6.3.3.9 Workunit1:ADV_RCR.1-9 

« 
The evaluator shall examine the correspondence analysis between the low-level design and the subset of the 

implementation representation to determine that the subset is a con'ect and complete representation of those 

portions of the low-level design that are refined in the implementation representation. 

Since the evaluator examines only a subset of the implementation representation, this work unit is performed 
by assessing the correspondence analysis of the subset of the implementation representation to the relevant 
parts of the iow-level design rather than attempting to trace each TQE security function into the 
implementation representation. The subset may provide no coverage for some functions. 

10.7 Guidance documents activity 

The purpose of the guidance document activity is to judge the adequacy of the documentation describing how 
to use the operational TOE. Such documentation includes both that aimed at trusted administrators and norv 
administrator users whose incon-ect actions could adversely affect the security of the TOE, as well as that 
aimed at untrusted users whose incorrect actions could adversely affect the security of their own data. 

10.7.1 Application notes 

The guidance documents activity applies to those functions and interfaces which are related to the security of 
the TOE. The secure configuration of the TOE is described in the ST. 

10.7.2 Evaluation of Administrator guidaace (AGD_ADM.1) 

10.7.2.1 Objectives 

The objective of this sub-activity is to determine whether the administrator guidance describes how to 
administer the TOE in a secure manner. 

10.7.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the life-cycle definition. 

10.7.2.3 Application notes 

The term "administrator" is used to indicate a human user who is trusted to perform security critical operations 
within the TOE, such as setting TOE configuration parameters. The operations may affect the enforcement of 
the TSP, and the administrator therefore possesses specific privileges necessary to perform those operations. 
The role of the administrator(s) has to be cleariy distinguished from the role of non-administrative users of the 

TOE. 

There may be different administrator roles or groups defined in the ST that are recognised by the TOE and 
that can interact with the TSF 5uch as auditor, administrator, or daily-management. Each role can enconrrpass 
an extensive set of capabilities, or can be a single one. The capabilities of these roles and their associated 
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privileges are described in the FMT class. Different administrator roles and groups should be taken into 
consideration by the administrator guidance. 

10.7.2.4 Action AGD.ADM.1 .1 E 

10.7.2.4.1 Work unit 1:AGD_ADM.1-1 

ISO/IEC 15408-3 AGD_ADM.1.1C: The administrator guidance shall describe the administrative functions and 
interfaces available to the administrator of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes the administrative 
security functions and interfaces available to the administrator of the TOE. 

The administrator guidance should contain an overview of the security functionality that is visible at the 
administrator interfaces. 

The administrator guidance should identify and describe the purpose, behaviour, and interrelationships of the 
administrator security interfaces and functions. 

For each administrator security interface and function, the administrator guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system calls, menu selection, command button); 

b) describe the parameters to be set by the administrator, their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

10.7.2.4.2 Wort unit 1 : AGD_ADM.1 -2 

ISO/IEC 15408-3 AGD_ADM.1 .2C: The administrator guidance shall describe how to administer the TOE in a 
secure manner 

The evaluator shall examine the administrator guidance to determine that it describes how to administer the 
TOE in a secure manner. 

The administrator guidance describes how to operate the TOE according to the TSP in an IT environment that 
is consistent with the one described in the ST. 

10.7.2.4.3 Woritunit1:AGD_ADIVI.1-3 

ISO/IEC 15408-3 AGD_ADM.1.3C: The administrator guidance shall contain warnings about functions and 
privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the administrator guidance to determine that it contains warnings about functions 
and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges to make use of the different 
functions of the TOE. This means that some users may be authorised to perform certain functions while other 
users may not be so authorised. These functions and privileges should be described by the administrator 
guidance. 

The administrator guidance identifies the functions and privileges that must be controlled, the types of controls 
required for them, and the reasons for such controls. Warnings address expected effects, possible side effects, 
and possible interactions with other functions and privileges. 
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10.7.2.4.4 Work unit 1:AGD_ADM.1-4 

ISO/IEC 15408-3 AGD_ADM.1.4C: The administrator guidance shall describe all assumptions regarding user 
behaviour that are relevant to secure operation of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes all assumptions 
regarding user behaviour that are relevant to the secure operation of the TOE. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the administrator guidance. 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

10.7.2.4.5 Work unit 1:AGD_ADM.1-5 

ISO/IEC 15408-3 AGD_ADM.1.5C: The administrator guidance shall describe all security parameters under 
the control of the administrator, indicating secure values as appropriate. 

The evaluator shall examine the administrator guidance to determine that it describes all security parameters 
under the control of the administrator indicating secure values as appropriate. 

For each security parameter, the administrator guidance should describe the purpose of the parameter, the 
valid and default values of the parameter, and secure and insecure use settings of such parameters, both 
individually or in combination. 

10.7.2.4.6 Work unit 1:AGD_ADIVI.1-6 

ISO/IEC 15408-3 AGD_ADM.1.6C: The administrator guidance shall describe each type of security-relevant 
event relative to the administrative functions that need to be performed, including changing the security 
characteristics of entities under the control of the TSF. 

The evaluator shall examine the administrator guidance to determine that it describes each type of security- 
relevant event relative to the administrative functions that need to be performed, including changing the 
security characteristics of entities under the control of the TSF. 

Atl types of security-rslevant events are detailed, such that an administrator knows what events may occur 
and what action (if any) the administrator may have to take in order to maintain security. Security-relevant 
events Ihat may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user 
records, such as when a user account is removed when the user leaves the organisation) are adequately 
defined to allow administrator intervention to maintain secure operation. 

10.7.2.4.7 Work unit 1:AGD_ADM.1-7 

ISO/IEC 15408-3 AGD_ADM.1.7C: The administrator guidance shall be consistent with all other 
documentation supplied for evaluation. 

The evaluator shall examine the administrator guidance to determine that it is consistent with all other 
documents supplied for evaluation. 

The ST in particular may contain detailed information on any warnings to the TOE administrators with regard 
to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 
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10.7.2.4.8 Workunit1:AGD ADM.1-8 



ISO/IEC 15408-3 AGD_ADM.1 .8C: The administrator guidance shall desciibe all security requirements for the 
IT environment that are relevant to the administrator 

The evaluator shall examine the administrator guidance to determine that it describes all IT security 
requirements for the IT environment of the TOE that are relevant to the administrator. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare them with the administrator guidance to ensure that all security requirements of the 
ST that^re relevant to the administrator are described appropriately in the administrator guidance. 

10.7.3 Evaluation of User guidance (AGD_USR.1) 

10.7.3.1 Objectives 

The objectives of this sub-activity are to determine whether the user guidance describes the security functions 
and interfaces provided by the TSF and whether this guidance provides instructions and guidelines for the 
secure use of the TOE. 

10.7.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures. 

10.7.3.3 Apptication notes 

There may be different user roles or groups defined in the ST that are recognised by the TOE and that can 
interact with the TSF. The capabilities of these roles and their associated privileges are described in the FMT 
class. Different user roles and groups should be taken into consideration by the user guidance. 

10.7.3.4 Action AGD_USR.1. IE 

10.7.3.4.1 Work unit 1:AGD_USR.1-1 

ISO/IEC 15408-3 AGD_USR.1.1C: The user guidance shall describe the functions and interfaces available to 
the non-administrative users of the TOE. 

The evaluator shall examine the user guidance to determine that it describes the security functions and 
interfaces available to the non-administrative users of the TOE. 

The user guidance should contain an overview of the security functionality that is visible at the user interfaces. 



75 



IS 15671 :2006 
ISO/IEC 18045 : 2005 

The user guidance should identify and describe the purpose of the security interfaces and functions. 

10.7.3.4.2 Work unit 1 :AGD_USR.1-2 

ISO/IEC 15408-3 AGD_USR.1.2C: The user guidance shall describe the use of user-accessible security 
functions provided by the TOE. 

The evaluator shall examine the user guidance to determine that it describes the use of user-accessible 
security functions provided by the TOE. 

The user guidance should identify and describe the behaviour and interrelationship of the security interfaces 
and functions available to the user. 

If the user is altowed to invoke a TOE security function, the user guidance provides a description of the 
interfaces available to the user for that function. 

For each interface and function, the user guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system call, menu selection, command button) ; 

b) describe the parameters to be set by the user and their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

10.7.3.4.3 Work unit 1:AGD_USR.1-3 

ISO/IEC 15408-3 AGD_USR.1.3C: The user guidance shall contain warnings about user-accessible functions 
and privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the user guidance to determine that it contains warnings about user-accessible 
functions and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges in making use of the different 
functions of the TOE. This means that some users are authorised to perform certain functions, while other 
users may not be so authorised. These user-accessible functions and privileges are described by the user 
guidance. 

The user guidance should identify the functions and privileges that can be used, the types of commands 
required for them, and the reasons for such commands. The user guidance should contain warnings regarding 
the use of the functions and privileges that must be controlled. Warnings should address expected effects, 
possible side effects, and possible interactions with other functions and privileges. 

10.7.3.4.4 Work unit 1 :AGD_USR.1-4 

ISO/IEC 15408-3 AGD_USR.1.4C: The user guidance shall clearly present all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

The evaluator shall examine the user guidance to determine that it presents all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

Assumptions about the user behaviour may be described in more detail In the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need he included in the user guidance. 
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The user guidance should provide advice regarding effective use of the security functions (e.g. reviewing 
password composition practices, suggested frequency of user file backups, discussion on the effects of 
changing user access privileges). 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

The user guidance should indicate whether the user can invoke a function or whether the user requires the 
assistance of an administrator. 

10.7.3.4.5 Work unit 1:AGD_USR.1-5 

ISO/IEC 15408-3 AGD_USR.1.5C: The user guidance shall be consistent with all other documentation 
supplied for evaluation. 

The evaluator shall examine the user guidance to determine that it is consistent with all other documentation 
supplied for evaluation. 

The evaluator ensures that the user guidance and al! other documents supplied for evaluation do not 
contradict each other. This is especially true if the ST contains detailed information on any warnings to the 
TOE users with regard to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 

1 0.7.3.4.6 Work unit 1 :AGD_USR.1 -6 

ISO/IEC 15408-3 AGD_USR.1.6C: The user guidance shall describe all security requirements for the IT 
environment that are relevant to the user. 

The evaluator shall examine the user guidance to determine that it describes all security requirements for the 
IT environment of the TOE that are relevant to the user. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare that with the user guidance to ensure that all security requirements of the ST, that are 
relevant to the user, are described appropriately in the user guidance. 

10.8 Tests activity 

The purpose of this activity is to determine, by independently testing a subset of the TSF, whether the TOE 
behaves as specified in the design documentation and in accordance with the TOE security functional 
requirements specified in the ST. 

10.8.1 Application notes 

The size and composition of the evaluator's test subset depends upon several factors discussed in the 
independent testing (ATEJND.1 Independent testing - conformance) sub-activity. One such factor affecting 
the composition of the subset is known public domain weaknesses, information to which the evaluator needs 
access {e.g. from a scheme). 

To create tests, the evaluator needs to understand the desired expected behaviour of a security function in the 
context of the requirements it is to satisfy. The evaluator may choose to focus on one security function of the 
TSF at :a time, examining the ST requirement and the relevant parts of the functional specification and 
guidance documentation to gain an understanding of the way the TOE is expected to behave. 
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10.8.2 Evaluation of Independent testing (ATEJND.i) 

10.8.2.1 Objectives 

The objective of this sub-activity is to determine whether the TOE behaves as specified by independently 
testing a subset of the TSF. 

10.8.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance; 

e) the secure installation, generation, and start-up procedures; 

f) the TOE suitable for testing. 

10.8.2.3 Action ATEJND.I. 1E 

10.8.2.3.1 Work unit 1:ATEJND.1-1 

ISO/iEC 1 5408-3 ATEJND.1 .1 C: The TOE shall be suitable for testing. 

The evaluator shall examine the TOE to determine that the test configuration is consistent with the 
configuration under evaluation as specified in the ST. 

The TOE used for evaluator testing should have the same unique reference as established by the 
ACM_CAP.1 Version numbers sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation.The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator's TOE test configurations should be consistent with each evaluated configuration described in 
the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that 
these resources are calibrated conrectly. 

10.8.2.3.2 Work unit 1:ATEJND.1-2 

The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. 

It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous 
successful completion of the ADOJGS.I Installation, generation, and start-up procedures sub-activity will 
satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed 
properly and is in a known state. If this is not the case, then the evaluator should follow the developer's 
procedures to install, generate and start up the TOE, using the supplied guidance only. 
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If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work 
unit when successfully completed could satisfy work unit AD0_IGS.1-2. 

10.8.2.4 Action ATEJND.1,2E 

10.8-2.4.1 Work ui^it 1 :ATEJND.1 -3 

The evaluator shall devise a test subset. 

The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing 
strategy woutd be to have the test subset contain as many security functions as possible tested with little 
rigour. Another testing strategy would be to have the test subset contain a few security functions based on 
their perceived relevance and rigorously test these functions. 

Typically the testing approach taken by the evaluator should fall somewhere between these two extremes. 
The evaluator should exercise most of the security functional requirements identified in the ST using at least 
one test, but testing need not demonstrate exhaustive specification testing. 

The evaluator, when selecting the subset of the TSF to be tested, should consider the followir\g factors: 

a) The number of security functions from which to draw upon for the test subset. Where the TOE includes 
only a small number of security functions, it may be practical to rigourously test all of the security 
functions. For TOEs with a large number of security functions this will not be cost-effective, and sampling 
is required. 

b) Maintaining a balance of evaluation activities. Testing typically occupies 20-30% of the evaluator effort 
during the evaluation. 

The evaluator selects the security functions to compose the subset. This selection will depend on a number of 
factors, and consideration of these factors may also influence the choice of test subset size; 

a) Known public domain weaknesses commonly associated with the type of TOE (e.g. operating system, 
firewall). Know public domain weaknesses associated with the type of TOE will influence the selection 
process of the test subset. The evaluator should include those security functions that address known 
public domain weaknesses for that type of TOE in the subset (know public domain weaknesses in this 
context does not refer to vulnerabilities as such but to inadequacies or problem areas that have been 
experienced with this particular type of TOE). If no such weaknesses are krrown, then a more general 
approach of selecting a broad range of security functions may be more appropriate. 

b) Significance of security functions. Those security functions more significant than others in terms of the 
security objectives for the TOE should be included in the test subset. 

c) Complexity of the security function. Complex security functions may require complex tests that impose 
onerous requirements on the developer or evaluator, which will not be conducive to cost-effective 
evaluations. Conversely, complex security functions are a likely area to find errors and are good 
candidates for the subset. The evaluator will need to strike a balance between these considerations. 

d) implicit testing. Testing some security functions may often implicitly test other security functions, and their 
inclusion in the subset may maximize the number of security functions tested (albeit implicitly). Certain 
interfaces will typically be used to provide a variety of security functionality, and will tend to be the target 
of an effective testing approach. 

e) Types of interfaces to the TOE (e.g. programmatic, command-line, protocol). The evaluator should 
consider including tests for all different types of interfaces that the TOE supports. 

f) Functions that are innovative or unusual. Where the TOE contains innovative or unusual security 
functions, which may feature strongly in marketing literature, these should be strong candidates for 

testing. 
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This guidance articulates factors to consider during the selection process of an appropriate test subset, but 
these are by no means exhaustive. 

For guidance on sampling see A.2, Sampling. 

10.8.2.4.2 Workunit1:ATEJND.1-4 

The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the 
tests to be reproducible. 

With an understanding of the expected behaviour of a security function, from the ST and the functional 
specification, the evaluator has to determine the most feasible way to test the function. Specifically the 
evaluator considers: 

a) the approach that will be used, for instance, whether the security function will be tested at an external 
interface, at an interna! interface using a test harness, or will an alternate test approach be employed (e.g. 
in exceptional circumstances, a code inspection); 

b) the security function interface(s) that will be used to stimulate the security function and observe 
responses; 

c) the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need 
to exist and security attributes they will need to have); 

d) special test equipment that will be required to either stimulate a security function (e.g. packet generators) 
or make observations of a security function (e.g. network analysers). 

The evaluator may find it practical to test each security function using a series of test cases, where each test 
case will test a very specific aspect of expected behaviour. 

The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant 
design specification, and to the ST, if necessary. 

10.8.2.4.3 Workunit1:ATEJND.1-5 

The evaluator shall conduct testing. 

The evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test 
documentation is used as a basis for testing but this does not preclude the evaluator from performing 
additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered 
during testing. These new tests are recorded in the test documentation. 

10.8.2.4.4 Workunit1:ATEJND.1-6 

The evaluator shall record the following information about the tests that compose the test subset: 

a) identification of the security function behaviour to be tested; 

b) instructions to connect and setup all required test equipment as required to conduct the test; 

c) instructions to establish all prerequisite test conditions; 

d) instructions to stimulate the security function; 

e) instructions for observing the behaviour of the security function; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 
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g) instructions to conclude the test and establisti the necessary post-test state for the TOE; 

h) actual test results. 

The level of detail should be such that another evaluator could repeat the tests and obtain an equivalent result. 
While some specific details of the test results may be different (e.g. time and date fields in an audit record) the 
overall result should be identical. 

There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. 
the actual test results of a test may not require any analysis before a comparison between the expected 
results can be made). The determination to omit this information is left to the evaluator, as is the justification. 

10.8.2.4.5 Work unit 1 : ATEJND.1 -7 

The evaluator shall check that all actual test results are consistent with the expected test results. 

Any differences in the actual and expected test results may indicate that the TOE does not perform as 
specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require 
corrective maintenance to the TOE or test documentation and perhaps require re-running of impacted tests 
and modifying the test sample size and composition. This determination is left to the evaluator, as is its 

justification. 

10.8.2.4.6 Work unit 1:ATEJND.1-8 

The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, 
depth and results. 

The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing activity during the evaluation. The intent of providing this 
information is to give a meaningful overview of the testing effort. It is not intended that the information 
regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. 
The intention is to provide enough detail to allow other evaluators and overseers to gain some insight about 
the testing approach chosen, amount of testing performed, TOE test configurations, and the overall results of 
the testing activity. 

Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested; 

b) subset size chosen. The amount of security functions that were tested during the evaluation and a 
justification for the size; 

c) selection criterra for the security functions that compose the subset. Brief statements about the factors 
considered when selecting security functions for inclusion in the subset; 

d) security functions tested. A brief listing of the security functions that merited inclusion in the subset; 

e) verdict for the activity. The overall judgement on the results of testing during the evaluation. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the testing the evaluator performed during the evaluation. 

11 EAL2 evaluation 

11.1 introduction 

EAL2 provides a low to moderate level of independently assured security. The security functions are analysed 
using a functional specification, guidance documentation, and the high-level design of the TOE to understand 
the security behaviour. The analysis is supported by independent testing of a subset of the TOE security 
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functions, evidence of developer testing based on the functional specification, selective confirmation of the 
developer test results, analysis of strength of functions, and evidence of a developer search for obvious. 
vulnerabilities. Further assurance is gained through a configuration list for the TOE and evidence of secure 
delivery procedures. 

11.2 Objectives 

The objective of this clause is to define the minimal evaluation effort for achieving an EAI^ evaluation and to 
provide guidance on ways and means of accomplishing the evaluation. 

11.3 EAL2 evaluation relationships 

An EAL2 evaluation covers the following: 

a) evaluation input task (Clause 7); 

b) EAL2 evaluation activities comprising the following: 

1) evaluation of the ST (Clause 9); 

2) evaluation of the configuration management (Subclause 1 1 .4); 

3) evaluation of the delivery and operation documents (Subclause 1 1 .5); 

4) evaluation of the development documents (Subclause 1 1 .6); 

5) evaluation of the guidance documents (Subclause 11.7); 

6) evaluation ofthe tests (Subclause 11.8); 

7) testing (Subclause 1 1 .8); 

8) evaluation of the vulnerability assessment (Subclause 1 1 .9); 

c) evaluation output task (Clause 7). 

The evaluation activities are derived from the EAL2 assurance requirements contained in ISO/(EC 15408-3. 

The ST evaluation is started prior to any TOE evaluation sub-activities since the ST provides the basis and 
context to perform these sub-activities. 

The sub-activities comprising an EAL2 evaluation are described in this clause. Although the sub-activities can, 
in general, be started more or less coincidentally, some dependencies between sub-activities have to be 
considered by the evaluator. 

For guidance on dependencies see Annex A 

11.4 Configuration management activity 

The purpose of the configuration management activity is to assist the consumer in identifying the evaluated 
TOE, and to ensure that configuration items are uniquely identified, 

11.4.1 Evaluation of CM capabilities (ACIUI_CAP.2) 

11.4.1.1 Objectives 

The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE and 
its associated configuration items. 
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tl.4.1.2 Input 

The evaluation evidence for this sul>activity is: 

a) tlieST; 

b) the TOE suitable for testing; 

c) the configuration management documentation, 

11.4.1.3 Application notes 

This component contains an implicit evaluator action to determine that the CM system is being used. As the 
requirements here are limited to identification of the TOE and provision of a configuration list, this action is 
aSready covered by. and limited to, the existing work units. At ACM_CAP.3 Authorisation controls the 
requirements are expanded beyond these two items, and more explicit evidence of operation is required. 

11 .4.1 .4 Action ACM_CAP.2.1 E 

1 1 .4.1.4.1 Work unit 2:ACM_CAP.2-1 

ISO/IEC 15408-3 ACM_CAP.2.1C: The mference for the TOE shall be unique to each version of the TOE. 

The evaluator shall check that the version of the TOE provided for evaluation is uniquely referenced. 

The evaluator should use the developer's CM system to validate the uniqueness of the reference. by checking 
the configuration list to ensure that the configuration items are uniquely identified. Evidence that the version 
provided for evaluation is uniquely referenced may be incomplete if only one version is examined during the 
evaluation, and the evaluator should look for a referencing system that is capable of supporting unique 
references (e.g. use of numbers, letters or dates). However, the absence of any reference will normally lead to 
a fail verdict against this requirement unless the evaluator is confident that the TOE can be uniquely identified. 

The evaluator should seek to examine more than one version of the TOE (e.g. during rework following 
discovery of a vulnerability), to check that the two versions are referenced differently. 

11.4.1.4.2 Work unit 2:ACM_CAP.2-2 

ISO/IEC 15408-3 ACM_CAP.2.2C: The TOE shall be labelled with its reference. 

The evaluator shall check that the TOE provided for evaluation is labelled with its reference. 

The evaluator should ensure that the TOE contains a unique reference such that it is possible to distinguish 
different versions of the TOE. This could be achieved through labelled packaging or media, or by a label 
displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the 
TOE (e.g. at the point of purchase or use). 

The TOE may provide a method by which it can be easily identified. For example, a software TOE may display 
its name and version number during the start up routine, or in response to a command line entry. A hardware 
or firmware TOE may be identified by a part number physically stamped on the TOE. 

11.4.1.4.3 Work unit 2:ACM_CAP.2-3 

The evaluator shall check that the TOE references used are consistent. 

If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible 
to relate any labelled guidance -documentation supplied as part of the TOE to the evaluated operational TOE. 
This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, 
that they have installed this version, and that they have the correct version of the guidance to operate the TOE 
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in accordance with its ST. The evaluator can use the configuration list that is part of the provided CM 
documentation to verify the consistent use of identifiers. 

The evaluator also verifies that the TOE reference is consistent with the ST. 

For guidance on consistency analysis see A.3, Consistency analysis. 

1 1 .4.1 .4.4 Work unit 2:ACM_CAP.2-4 

ISO/IEC 15408-3 ACM_CAP.2.3C: The CM documentation st}all include a configuration list. 
The evaluator shall check that the CM documentation provided includes a configuration list. 
A configuration list identifies the items being maintained under configuration control. 

1 1 .4.1 .4.5 Work unit 2:ACIVI_CAP.2-5 

ISO/IEC 15408-3 ACM_CAP.2.4C: The configuration list shall uniquely identify all configuration items that 
comprise the TOE. 

The evaluator shall check that the configuration list uniquely identifies each configuration item. 

The configuration list contains a list of the configuration items that comprise the TOE, together with sufficient 
information to uniquely identify which version of each item has been used (typically a version number). Use of 
this list will enable the evaluator to check that the correct configuration items, and the correct version of each 
item, have been used during the evaluation. 

1 1 .4.1 .4.6 Work unit 2:ACIVI„CAP.2.6 

ISO/IEC 15408-3 ACM_CAP.2.5C: The configuration list shall describe the configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration list to determine that it identifies the configuration items that 
comprise the TOE. 

The minimum scope of configuration items to be covered in the configuration list is given by CM scope 
{ACM_SCP). If no CM scope (ACM_SCP) component is included, the evaluator should assess the adequacy 
of the list on the basis of the approach taken by the developer to CM, taking the requirements of ACM_SCP.1 
TOE CM coverage as an upper bound (since it would be unreasonable to expect more than is required there). 
For example, when a change is made to the TOE or any item of documentation, the evaluator may observe or 
enquire at what level of granularity the item is re-issued. This granularity should correspond to the 
configuration items that appear in the configuration list. 

1 1 .4.1 .4.7 Work unit 2:ACIVI_CAP.2-7 

ISO/IEC 15408-3 ACM_CAP.2.6C: The CM documentation shall describe the method used to uniquely identify 
the configuration items that comprise the TOE. 

The evaluator shall examine the method of identifying configuration items to determine that it describes how 
configuration items are uniquely identified. 

11.4.1.4.8 Work unit 2:ACM_CAP.2-8 

ISO/IEC 1 5408-3 ACM_CAP.2.7C: The CM system shall uniquely identify all configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration items to determine that they are identified in a way that is 
consistent with the CM documentation. 
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Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers 
for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration 
items that are submitted by the developer as evaluation evidence, the evaluator confirms that each 
configuration item possesses a unique identifier in a manner consistent with the unique identification method 
that is described in the CM documentation. 

11.5 Delivery and operation activity 

The purpose of the delivery and operation activity is to judge the adequacy of the documentation of the 
procedures used to ensure that the TOE is installed, generated, and started in the same way the developer 
intended it to be and that it is delivered without modification. This inciudesboth the procedures taken while the 
TOE is in transit, as well as the initialisation, generation, and start-up procedures. 

11.5.1 Evaluation of Delivery (AD0_DEL1) 

11.5.1.1 Objectives 

The objective of this sub-activity is to determine whether the delivery documentation describes all procedures 
used to maintain security of the TOE when distributing the TOE to the user's site. 

11.5.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the delivery documentation. 

11.5.1.3 Action AD0_DEL.1.1E 

11.5.1.3.1 Workunit2:ADO_DEL.1-1 

ISO/IEC 15408-3 AD0_DEL.1.1C: The delivery documentation shall describe all procedures that are 
necessary to maintain security when distributing versions of the TOE to a user's site. 

The evaluator shall examine the delivery documentation to determine that it describes all procedures that are 
necessary to maintain security when distributing versions of the TOE or parts of it to the user's site. 

Interpretation of the term "necessary" will need to consider the nature of the TOE and information contained in 
the ST. The level of protection provided should be commensurate with the assumptions, threats, 
organisational security policies, and security objectives identified in the ST. In some cases these may not be 
explicitly expressed in relation to delivery. The evaluator should determine that a balanced approach has been 
taken, such that delivery does not present an obvious weak point in an otherwise secure development process. 

The delivery procedures describe proper procedures to determine the identification of the TOE and to 
maintain integrity during transfer of the TOE or its component parts. The procedures describe which parts of 
the TOE need to be covered by these procedures. It should contain procedures for physical or electronic (e.g. 
for downloading off the Internet) distribution where applicable. The delivery procedures refer to the entire TOE, 
including applicable software, hardware, firmware and documentation. 

The emphasis in the delivery documentation is likely to be on measures related to integrity, as technical 
measures are required to be applied to maintain integrity during the TOE delivery. However, confidentiality 
and availability of the delivery will be of concern in the delivery of some TOEs; procedures relating to these 
aspects of the secure delivery should also be discussed in the procedures. 

The delivery procedures should be applicable across all phases of delivery from the production environment to 
the installation environment (e.g. packaging, storage and distribution). 

Standard commercial practice for packaging and delivery may be acceptable. This includes shrink wrapped 
packaging, a security tape or a sealed envelope. For the distribution, the public mail or a private distribution 
service may be acceptable. 
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The suitability of the choice of the delivery procedures is Influenced by the TOE (e.g. whether it Is software or 
hardware) and by the security objectives. In cases where the delivery procedures differ for different parts of 
the TOE, the totality of procedures are suitable to meet the overall security objectives. 

11.5.i.4 Implied evaluator action 

1 1 .5.1 .4.1 Work unit 2: ADO_DEL.1 -2 

ISO/IEC 15408-3 AD0_DEL.1. 2D: The developer shall use the delivery procedures. 

The evaluator shall examine aspects of the delivery process to determine that the delivery procedures are 

used. 

The approach taken by the evaluator to check the application of delivery procedures will depend on the nature 
of the TOE, and the delivery process itself. In addition to examination of the procedures themselves, the 
evaluator should seek some assurance that they are applied in practice. Some possible approaches are: 

a) a visit to the distribution site(s) where practical application of the procedures may be observed; 

b) examination of the TOE at some stage during delivery, or at the user's site (e.g. checking for tamper proof 

seals); 

c) observing that the process is applied in practice when the evaluator obtains the TOE through regular 
channels; 

d) questioning end users as to how the TOE was delivered. 

For guidance on site visits see A. 5, Site Visits. 

It may be the case of a newly developed TOE that the delivery procedures have yet to be exercised. In these 
cases, the evaluator has to be satisfied that appropriate procedures and facilities are in place for future 
deliveries and that all personnel involved are aware of their responsibilities. The evaluator may request a "dry 
run" of a delivery if this is practical. If the developer has produced other similar products, then an examination 
of procedures in their use may be useful in providing assurance. 

11.5.2 Evaluation oflnstallation, generation and start-up (AD0JGS.1) 

11.5.2.1 Objectives 

The objective of this sub-activity is to determine whether the procedures and steps for the secure installation, 
generation, and start-up of the TOE have been documented and result in a secure configuration. 

11.5.2.2 input 

The evaluation evidence for this sub-activity is; 

a) the administrator guidance; 

b) the secure installation, generation, and start-up procedures; 

c) the TOE suitable for testing. 

11.5.2.3 Appiication notes 

The installation, generation, and start-up procedures refer to all installation, generation, and start-up 
procedures, regardless of whether they are performed at the user's site or at the development site that are 
necessary to progress the TOE to the secure configuration as described in the ST. 
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1 1 .5.2.4 Action ADOJGS.1 .1 E 

t1 .5.2.4.1 Work unit 2:AD0JGS.1-1 

ISO/IEC 15408-3 ADOJGS.I 1C: The installation, generation and start-up documentation shall describe all 
the steps necessary for secure installation, generation and start-up of the TOE. 

The evaluator shall check that the procedures necessary for the secure installation, generation and start-up of 
the TOE have been provided. 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be .satisfied. 

11.5.2.5 Action ADOJGS.I. 2E 

11.5.2.5.1 Work unK 2: ADOJGS.I -2 

The evaluator shall examine the provided installation, generation, and start-up procedures to determine that 
they describe the steps necessary for secure installation, generation, and start-up of the TOE. 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

The installation, generation, and start-up procedures may provide detailed information about the following: 

a) changing the installation specific security characteristics of entities under the control of the TSF; 

b) handling exceptions and problems; 

c) minimum system requirements for secure installation if applicable. 

In order to confirm that the installation, generation, and start-up procedures result in a secure configuration, 
the evaluator may follow the developer's procedures and may perform the activities that customers are usually 
expected to perform to install, generate, and start-up the TOE (if applicable to the TOE), using the supplied 
guidance documentation only. This work unit might be performed in conjunction with the ATE„IND.1-2 work 
unit. 

11.6 Development activity 

The purpose of the development activity is to assess the design documentation in terms of its adequacy to 
understand how the TSF provides the security functions of the TOE. This understanding is achieved through 
examination of increasingly refined descriptions of the TSF design documentation. Design documentation 
consists of a functional specification (which describes the external interfaces of the TOE) and a high-level 
design (which describes the architecture of the TOE in terms of internal subsystems). There is also a 
representation correspondence (which maps representations of the TOE to one another in order to ensure 
consistency). 

11.6.1 Application notes 

ISO/IEC 15408 requirements for design documentation are levelled by formality. ISO/IEC 15408 considers a 
document's degree of formality (that is, whether it is informal, semiformal or formal) to be hierarchical. An 
informal document is one that is expressed in a natural language. The methodology does not dictate the 
specific language that must be used; that issue is left for the scheme. The following paragraphs differentiate 
the contents of the different informal documents. 

An informal functional specification comprises a description the security functions (at a level similar to that of 
the TOE summary specification) and a description of the externally-visible interfaces to the TSF. For example. 
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if an operating system presents tfie user with a means of self-identification, of creating files, of modifying or 
deleting files, of setting permissions defining what other users may access files, and of communicating with 
remote machines, its functional specification would contain descriptions of each of these functions. If there are 
also audit functions that detect and record the occurrences of such events, descriptions of these audit 
functions would also be expected to be part of the fijnctionai specification; while these functions are 
technically not directly invoked by the user at the extemal interface, they certainly are affected by what occurs 
at the user's external interface. 

An informal high-level design is expressed in terms of sequences of actions that occur in each subsystem in 
response to stimulus at its interface. For example, a firewall might be composed of subsystems that deal with 
packet filtering, with remote administration, with auditing, and with connection-level filtering. The high-level 
design description of the firewall would describe the actions that are taken, in temns of what actions each 
subsystem takes when an incoming packet arrives at the firewall. 

Informality of the demonstration of correspondence need not be in a prose form; a simple two-dimensional 
mapping may be sufficient. For example, a matrix with modules listed along one axis and subsystems listed 
along the other, with the cells identifying the correspondence of the two, would serve to provide an adequate 
informal correspondence between the high-level design and the low-levet design. 

11.6.2 Evaluation of Functional specirication (ADV_FSP.1) 

11.6.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has provided an adequate description 
of the security functions of the TOE and whether the security functions provided by the TOE are sufficient to 
satisfy the security functional requirements of the ST. 

11.6.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance. 

11.6.2.3 Action ADV_FSP.1. IE 

1 1 .6.2.3.1 Work unit 2:ADV_FSP.1 -1 

ISO/IEC 15408-3 ADV_FSP.1.1C: The functional specification shall describe the TSF and its extemal 
interfaces using an informal style. 

The evaluator shall examine the functional specification to determine that it contains all necessary infomial 
explanatory text. 

If the entire functional specification is informal, this work unit is not applicable and is therefore considered to 
be satisfied. 

Supporting narrative descriptions are necessary for those portions of the functional specification that are 
difficult to understand only from the semiformal or formal description (for example, to make clear the meaning 
of any formal notation). 

1 1 .6.2.3.2 Work unit 2:ADV_FSP.1-2 

ISO/IEC 15408-3 ADV_FSP.1 .2C: The functional specirication shall be internally consistent. 
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The evaluator shall examine the functional specification to determine that it is internally consistent. 

The evaluator validates the functional specification by ensuring that the descriptions of the interfaces making 
up the TSFI are consistent with the descriptions of the functions of the TSF 

1 1 .6.2.3.3 Work unit 2:ADV_FSP.1 -3 

ISO/IEC 15408-3 ADV_FSP.1.3C: The functional specification shall describe the purpose and method of use 
of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. 

The evaluator shall examine the functional specification to determine that it identifies all of the external TOE 
security function interfaces. 

The term external refers to that which is visible to the user. External interfaces to the TOE are either direct 
interfaces to the TSF or interfaces to non-TSF portions of the TOE. However, these non-TSF interfaces might 
have eventual access to the TSF. These external interfaces that directly or indirectly access the TSF 
collectively make up the TOE security function interface (TSFI). Figure 6 shows a TOE with TSF (cross- 
hatched) portions and non-TSF (empty) portions. This TOE has three external interfaces: interface c is a direct 
interface to the TSF; interface b is an indirect interface to the TSF; and interface a is an interface to non-TSF 
portions of the TOE. Therefore, interfaces b and c make up the TFSI. 




TOE 



Figure 7 - TSF Interfaces 

It should be noted that all security functions reflected in the functional requirements of ISO/IEC 15408-2 (or in 
extended components thereof) will have some sort of externally-visible manifestation. While not all of these 
are necessarily interfaces from which the security function can be tested, they are all externally-visible to 
some extent and must therefore be included in the functional specification. 

11.6.2.3.4 Work unit 2:ADV_FSP.1-4 

The evaluator shall examine the functional specification to determine that it describes all of the external TOE 
security function interfaces. 

For a TOE that has no threat of malicious users (i.e. TSF physical protection (FPT_PHP), Reference 
mediation (FPT_RVM), and Domain separation (FPT_SEP) are rightfully excluded from its ST), the only 
interfaces that are described in the functional specification (and expanded upon in the other TSF 
representation descriptions) are those to and from the TSF. The absence of TSF physical protection 
(FPT_PHP). Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) presumes there is no 
concern for any sort of bypassing of the security features; therefore, there is no concern with any possible 
impact that other interfaces might have on the TSF. 
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On the other hand, if the TOE has a threat of malicious users or bypass (i.e. TSF physical protection 
{FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) are included in its ST), all 
external interfaces are described in the functional specification, but only to the extent that the effect of each is 
made clear: interfaces to the security functions (i.e. interfaces b and c In Figure 6) are completely described, 
while other interfaces are described only to tbe extent that it is clear that the TSF is inaccessible through the 
interface (i.e. that the interface is of type a, rather than b in Figure 6). The inclusion of TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) implies a concern that all 
interfaces might have some effect upon the TSF. Because each external interface is a potential TSF interface, 
the functional specification must contain a description of each interface in sufficient detail so that an evaluator 
can determine whether the interface is security relevant. 

Some architectures lend themselves to readily provide this interface description in sufficient detail for groups 
of external interfaces. For example, a kernel architecture is such that all calls to the operating system are 
handled by kernel programs; any calls that might violate the TSP must be called by a program with the 
privilege to do so. All programs that execute with privilege must be included in the functional specification. Any 
program external to the kernel that .executes without privilege is incapable of affecting the TSP (i.e. such 
programs are interfaces of type a, rather than* b in Figure 6) and may, therefore, be excluded from the 
functional specification. It is worth noting that, while the evaluator's understanding of the interface description 
can be expedited in cases where there is a kernel architecture, such an architecture is not necessary. 

11.6.2.3.5 Workunit2:ADV_FSP.1-5 

The evaluator shall examine the presentation of the TSFI to determine that it adequately and correctly 
describes tbe behaviour of the TOE at each external interface describing effects, exceptions and error 
messages. 

In order to assess the adequacy and correctness of an interface's presentation, the evaluator uses the 
functional specification, the TOE summary specification of the ST, and the user and administrator guidance to 
assess the following factors: 

a) All security relevant user input parameters (or a characterisation of those parameters) should be identified. 
For completeness, parameters outside of direct user control should be identified if they are usable by 
administrators. 

b) All security relevant behaviour described in the reviewed guidance should be reflected in the description 
of semantics in the functional specification. This should include an identification of the behaviour in terms 
of events and the effect of each event. For example, if an operating system provides a rich file system 
interface, where it provides a different error code for each reason why a file is not opened upon request 
(e.g. access denied, no such file, file is in use by another user, user is not authorised to open the file after 
5pm, etc.), the funcfional specification should explain that a file is either opened upon request, or else that 
an error code is returned. (While the functional specification may enumerate all these different reasons for 
errors, it need not provide such detail.) The description of the semantics should include how the security 
requirements apply to the interface (e.g. whether the use of the interface is an auditable svent and, if so, 
the information that can be recorded). 

c) All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, 
the description of the interface should explain how the interface behaves in the presence or absence of 
privilege. 

d) The information contained in the descriptions of the security relevant parameters and syntax of the 
interface should be consistent across all documentation. 

Verification of the above is done by reviewing the functional specification and the TOE summary specification 
of the ST, as well as the user and administrator guidance provided by the developer. For example, if the TOE 
were an operating system and its underlying hardware, the evaluator would look for discussions of user- 
accessible programs, descriptions of protocols used to direct the activities of programs, descriptions of user- 
accessible databases used to direct the activities of programs, and for user interfaces (e.g. commands, 
application program interfaces) as applicable to the TOE under evaluation; the evaluator would also ensure 
that the processor instruction set is described. 
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This review might be iterative, such that the evaluator would not discover the functional specification to be 
incomplete until the design, source code, or other evidence is examined and found to contain parameters or 
error messages that have been omitted from the functional specification. 

11,6.2.3.6 Workunit2:ADV_FSP.1-6 

ISO/IEC 15408-3 ADV_FSP.1 .4C; The functional specification shall completely represent the TSF. 

The evaluator shall examine the functional specification to determine that the TSF is fully represented. 

In order to assess the completeness of the TSF representation, the evaluator consults the TOE summary 
specification of the ST, the user guidance, and the administrator guidance. None of these should describe 
security functions that are absent from the TSF presentation of the functional specification. 

1 16.2.4 Action ADV_FSP.1 .2E 

11. 6.2.4.1 Work unit 2:ADV_FSP.1-7 

The evaluator shall examine the functional specification to determine that it is a complete instantiation of the 
TOE security functional requirements. 

To ensure that all ST security functional requirements are covered by the functional specification, the 
evaluator may construct a map between the TOE summary specification and the functional specification. Such 
a map might be already provided by the developer as evidence for meeting the correspondence 
(Representation correspondence (ADV_RCR).*) requirements, in which case the evaluator need only verify 
the completeness of this mapping, ensuring that all security functional requirements are mapped onto 
applicable TSFI presentations in the functional specification. 

11.6.2.4.2 Workunit2:ADV_FSP.1-8 

The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the 
TOE security functional requirements. 

For each interface to a security function with specific characteristics, the detailed information in the functional 
specification must be exactly as it is specified in the ST. For example, if the ST contains user authentication 
requirements that the password length must be eight characters, the TOE must have eight-character 
passwords; if the functional specification describes six-character fixed length passwords, the functional 
specification would not be an accurate instantiation of the requirements. 

For each interface in the functional specification that operates on a controlled resource, the evaluator 
determines whether it returns an error code that indicates a possible failure due to enforcement of one of the 
security requirements; if no error code is returned, the evaluator determines whether an error code should be 
returned. For example, an operating system might present an interface to OPEN a controlled object. The 
description of this interface may include an error code that indicates that access was not authorised to the 
object. If such an error code does not exist, the evaluator should confirm that this is appropriate (because, 
perhaps, access mediation is performed on READs and WRITES, rather than on OPENs). 

11.6.3 Evaluation of High-level design (ADV_HLD.1) 

11.6.3.i Objectives 

The objective of this sub-activity is to determine whether the high-level design provides a description of the 
TSF in terms of major structural units (i.e. subsystems), and is a correct realisation of the functional 
specification. 
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11.6.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design. 

11.6.3.3 Action ADV_HLD.1. IE 

11 .6.3.3.1 Work unit 2:ADV_HLD.1-1 

ISO/IEC 15408-3 ADV_HLD.1 .1C: The presentation of the high-levei design shall be infonnal. 

The evaluator shall examine the high-level design to detennlne that it contains all necessary informal 
explanatory text. 

If the entire high-level design is informal, this work unit is not applicable and is therefore considered to be 
satisfied. 

Supporting narrative descriptions are necessary for those portions of the high-level design that are difficult to 
understand only from the semiformal or formal description {for example, to make clear the meaning of any 
formal notation). 

11.6.3.3.2 Work unit 2:ADV_HLD.1-2 

ISO/IEC 15408-3 ADV_HLD.1 .2C: The high-level design shall be internally consistent. 

The evaluator shall examine the presentation of the high-level design to determine that it is intemaily 
consistent. 

For guidance on consistency analysis see A.3, Consistency analysts. 

The evaluator validates the subsystem interface specifications by ensuring that the Interface specifications are 
consistent with the description of the purpose of the subsystem. 

11.6.3.3.3 Workunit2:ADV_HLD.1-3 

ISO/IEC 15408-3 ADV_HLD.1.3C: The high-level design shall describe the structure of the TSF in tenms of 
subsystems. 

The evaluator shall examine the high-level design to determine that the TSF is described in tenns of 
subsystems. 

With respect to the high-level design, the term subsystem refers to large, related units (such as memory- 
management, file-management, process-management). Breaking a design into the basic functional areas aids 
in the understanding of the design. 

The primary purpose for examining the high-level design is to aid the evaluator's understanding of the TOE. 
The developer's choice of subsystem definition, and of the grouping of TSFs within each subsystem, are an 
important aspect of making the high-level design useful in understanding the TOE's intended operation. As 
part of this work unit, the evaluator should make an assessment as to the appropriateness of the number of 
subsystems presented by the developer, and also of the choice of grouping of functions within subsystems. 
The evaluator should ensure that the decomposition of the TSF into subsystems is sufficient for the evaluator 
to gain a high-level understanding of how the functionality of the TSF is provided. 

The subsystems used to describe the high-level design need not be called "subsystems", but should represent 
a similar level of decomposition. For example, the design may be decomposed using "layers" or "managers". 
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11.6.3.3.4 Work unit 2:ADV_HLD.1-4 



ISO/IEC 15408-3 ADV_HLD.1.4C: The high-level design shall describe the security functionality provided by 
each subsystem of the TSF. 

The evaluator shall examine the high-level design to determine that it describes the security functionality of 
each subsystem. 

The security functional behaviour of a subsystem is a description of what the subsystem does. This should 
include a description of any actions that the subsystem may be directed to perform through its functions and 
the effects the subsystem may have on the security state of the TOE (e.g. changes in subjects, objects, 
security databases). 

11.6.3.3.5 Work unit 2:ADV_HLD.1-5 

ISO/IEC 15408-3 ADV_HLD.1.5C: The high-level design shall identify any underiying hardware, firmware, 
and/or software required by the TSF with a presentation of the functions provided by the supporting protection 
mechanisms implemented in that hardware, finrmare, or software. 

The evaluator shati check the high-level design to determine that it identifies all hardware, firmware, and 
software required by the TSF. 

If the ST contains no security requirements for the IT environment, this work unit is not applicable and is 
therefore considered to be satisfied. 

If the ST contains the optional statement of security requirements for the IT environment, the evaluator 
compares the list of hardware, firmware, or software required by the TSF as stated in the high-level design to 
the statement of security requirements for the IT environment to determine that they agree. The information in 
the ST characterises the underlying abstract machine on which the TOE will execute. 

If the high-level design includes security requirements for the IT environment that are not included in the ST, 
or if they differ from those included in the ST, this inconsistency is assessed by the evaluator under Action 
ADV_HLD.1.2E. 

11.6.3.3.6 Work unit2:ADV_HLD.1-6 

The evaluator shall examine the high-level design to determine that it includes a presentation of the functions 
provided by the supporting protection mechanisms implemented in the underlying hardware, firmware, or 
software. 

If the ST contains no security requirements for the IT environment, this work unit is not applicable and is 
therefore considered to be satisfied. 

The presentation of the functions provided by the underlying abstract machine on which the TOE executes 
need not be at the same level of detail as the presentation of functions that are part of the TSF. The 
presentation should explain how the TOE uses the functions provided in the hardware, firmware, or software 
that implement the security requirements for the IT environment that the TOE is dependent upon to support 
the TOE security objectives. 

The statement of security requirements for the IT environment may be abstract, particularly if it is intended to 
be capable of being satisfied by a variety of different combinations of hardware, firmware, or software. As part 
of the Tests activity, where the evaluator is provided with at least one instance of an underlying machine that 
is claimed to satisfy the security requirements for the IT environment, the evaluator can determine whether it 
provides the necessary security functions for the TOE. This determination by the evaluator does not require 
testing or analysis of the underlying machine; it is only a determination that the functions expected to be 
provided by it actually exist. 
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11.6.3.3.7 Work unit 2:ADV_HLD.1-7 

ISO/IEC 15408-3 ADV_HLD.1.6C: The high-level design shall identify all interfaces to the subsystems of the 
TSF. 

The evaluator shall check that the high-level design identifies the interfaces to the TSF subsystems. 

The high-level design includes, for each subsystem, the name of each of its entry points. 

1 1 .6.3.3.8 Work unit 2:ADV_HLD.1-8 

ISO/IEC 15408-3 ADV_HLD.1.7C: The high-level design shall identify which of the interfaces to the 
subsystems of the TSF are externally visible. 

The evaluator shall check that the high-level design identifies which of the interfaces to the subsystems of the 
TSF are externally visible. 

1 1 .6.3.4 Action ADV_HLD,1 .2E 

11.6.3.4.1 Workunit2:ADV_HLD.1-9 

The evaluator shall examine the high-level design to determine that it is an accurate instantiation of the TOE 
security functional requirements. 

The evaluator analyses the high-level design for each TOE security function to ensure that the function is 
accurately described. The evaluator also ensures that the function has no dependencies that are not included 
in the high-level design. 

The evaluator also analyses the security requirements for the IT environment in both the ST and the high-level 
design to ensure that they agree. For example, if the ST includes TOE security functional requirements for the 
storage of an audit trail, and the high-level design stated that audit trail storage is provided by the IT 
environment, then the high-level design is not an accurate instantiation of the TOE security functional 
requirements. 

11.6.3.4.2 Work unit 2:ADV_HLD.1 -10 

The evaluator shall examine the high-level design to determine that it is a complete instantiation of the TOE 
security functional requirements. 

To ensure that all ST security functional requirements are covered by the high-level design, the evaluator may 
construct a map between the TOE security functional requirements and the high-level design. 

11.6.4 Evaluation of Representation correspondence (ADV_RCR.1) 

11.6.4.1 Objectives 

The objective of this sub-activity is to determine whether the developer has correctly and completely 
implemented the requirements of the ST and functional specification in the high-level design. 

11.6.4.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 



94 



1815671:2006 
ISO/lEC 18045 : 2005 

d) the correspondence analysis between the TOE summary specification and the functional specification; 

e) the correspondence analysis between the functional specification and the high-level design; 
11.6.4.3 Action ADV_RCR.1 .1 E 

11.6.4.3.1 Work unit 2:ADV_RCR.1-1 

ISO/lEC 15408-3 ADV_RCR.1.1C: For each adjacent pair of provided TSF representations, the analysis shall 
demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and 
Completely refined in the less abstract TSF representation. 

The evaluator shall examine the correspondence analysis between the TOE summary specrftcation and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

11.6.4.3.2 Workunit2:ADV_RCR.1-2 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same, if the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

11.6.4.3.3 Workunit2:ADV_RCR.1-3 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, tlie evaluator 
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verifies that tiie security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding Interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

11.6.4.3.4 Work unit 2:ADV_RCR.1-4 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.2-8 and ADV_FSP.2-9. 

11.6.4.3.5 Work unit 2:ADV_RCR.1-5 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

11.6.4.3.6 Workunit2:ADV_RCR.1-6 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the corespondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

1 1 .6.4.3.7 Work unit 2:ADV_RCR.1 -7 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensiure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 
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11.6.4.3.8 Work unit 2:ADV.RCR.1-8 



The evaluator shall examine the correspondence analysis between the high-level design and the low-level 
design to determine that the low-level design is a correct and complete representation of the high-level design. 

The evaluator uses the correspondence analysis, the high-level design, and the low-level design to ensure 
that it is possible to map each TSF module identified in the low-level design onto a TSF subsystem described 
in the high-level design. For each TOE security function, the correspondence indicates which TSF modules 
are involved in the support of the function. The evaluator verifies that the low-level design includes a 
description of a connect realisation of each security function. 

11.6.4.3.9 Work unit 2:ADV_RCR.1-9 

The evaluator shall examine the correspondence analysis between the low-level design and the subset of the 
implementation representation to determine that the subset is a correct and complete representation of those 
portions of the low-level design that are refined in the implementation representation. 

Since the evaluator examines only a subset of the implementation representation, this work unit is performed 
by assessing the correspondence analysis of the subset of the implementation representation to the relevant 
parts of the low-level design rather than attempting to trace each TOE security function into the 
implementation representation. The subset may provide no coverage for some functions. 

11.7 Guidance documents activity 

The purpose of the guidance document activity is to judge the adequacy of the documentation describing how 
to use the operational TOE. Such documentation includes both that aimed at trusted administrators and non- 
administrator users whose incorrect actions could adversely affect the security of the TOE, as well as that 
aimed at untrusted users whose incorrect actions could adversely affect the security of their own data. 

11.7.1 Application notes 

The guidance documents activity applies to those functions and interfaces which are related to the security of 
the TOE. The secure configuration of the TOE is described in the ST. 

11.7.2 Evaluation of Administrator guidance (AGD_ADM.1) 

11.7.2.1 Objectives 

The objective of this sub-activity is to determine whether the administrator guidance describes how to 
administer the TOE in a secure manner. 

11.7.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the life-cycle definition. 
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1 1 .7.2.3 Application notes 

The term "administrator" is used to indicate a liuman user who is trusted to perform security critica) operations 
within the TOE. such as setting TOE configuration parameters. The operations may affect the enforcement of 
the TSP, and the administrator therefore possesses specific privileges necessary to perform those operations. 
The role of the administrator(s) has to be clearly distinguished from the role of non-administrative users of the 
TOE. 

There may be different administrator roles or groups defined in the ST that are recognised by the TOE and 
that can interact with the TSF such as auditor, administrator, or daily-management. Each role can encompass 
an extensive set of capabilities, or can be a single one. The capabilities of these roles and their associated 
privileges are described in the FMT class. Different administrator roles and groups should be taken into 
consideration by the administrator guidance. 

11.7.2.4 Action AGD_ADIVI.i. IE 

11.7.2.4.1 Work unit 2:AGD_ADI\/I.1-1 

ISO/IEC 1 5408-3 AGD_ADM. 1 .10: The administrator guidance shall describe the administrative functbns and 
interfaces available to the adrmnistrator of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes the administrative 
security functions and interfaces available to the administrator of the TOE. 

The administrator guidance should contain an overview of the security functionality that is visible at the 
administrator interfaces. 

The administrator guidance should identify and describe the purpose, behaviour, and interrelationships of the 
administrator security interfaces and functions. 

For each administrator security interface and function, the administrator guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programmtng-ianguage 
system calls, menu selection, command button); 

b) describe the parameters to be set by the administrator, their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

1 1 .7.2.4.2 Work unit 2:AGD_ADM.1-2 

ISO/IEC 15408-3 AGD_ADM.1.2C: The administrator guidance shall describe how to administer the TOE in a 
secure manner 

The evaluator shall examine the administrator guidance to determine that it describes how to administer the 
TOE in a secure manner. 

The administrator guidance describes how to operate the TOE according to the TSP in an IT environment that 
is consistent with the one described in the ST. 

11.7.^.4.3 Workunlt2:AGD_ADM.1-3 

ISO/lEC 15408-3 AGD_ADM.1.3C: The administrator guidance shall contain warnings about functions and 
privileges that should be controlled in a secure processing environment 

The evaluator shall examine the administrator guidance to determine that it contains warnings about functions 
and privileges that should be controlled in a secure processing environment. 
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The configuration of the TOE may allow users to have dissimilar privileges to make use of the different 
functions of the TOE. This means that some users may be authorised to perform certain functions while other 
users may not be so authorised. These functions and privileges should be described by the administrator 
guidance. 

The administrator guidance identifies the functions and privileges that must be controlled, the types of controls 
required for them, and the reasons for such controls. Warnings address expected effects, possible side effects, 
and possible interactions with other functions and privileges. 

11.7.2.4.4 Workunit2:AGD_ADM.1-4 

ISO/IEC 15408-3 AGD_ADM.1.4C: The administrator guidance shall describe all assumptions regarding user 
behaviour that are relevant to secure operation of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes all assumptions 
regarding user behaviour that are relevant to the secure operation of the TOE. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the administrator guidance. 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

11.7.2.4.5 Workunit2:AGD_ADM.1-5 

ISO/IEC 15408-3 AGD_ADM.1.5C: The administrator guidance shall describe all security parameters under 
the control of the administrator, indicating secure values as appropriate. 

The evaluator shall examine the administrator guidance to determine that it describes all security parameters 
under the control of the administrator indicating secure values as appropriate. 

For each security parameter, the administrator guidance should describe the purpose of the parameter, the 
valid and default values of the parameter, and secure and insecure use settings of such parameters, both 
individually or in combination. 

11.7.2.4.6 Workunit2:AGD_ADM.1-6 

ISO/IEC 15408-3 AGD_ADM.1.6C: The administrator guidance shall describe each type of security-relevant 
event relative to the administrative functions that need to be performed, including changing the security 
characteristics of entities under the control of the TSF. 

The evaluator shall examine the administrator guidance to determine that it describes each type of security- 
relevant event relative to the administrative functions that need to be performed, including changing the 
security characteristics of entities under the control of the TSF. 

All types of security-relevant events are detailed, such that an administrator knows what events may occur 
and what action (if any) the administrator may have to take in order to maintain security. Security-relevant 
events that may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user 
records, such as when a user account is removed when the user leaves the organisation) are adequately 
defined to allow administrator intervention to maintain secure operation. 

11.7.2.4.7 Workunit2:AGD_ADM.1-7 

ISO/IEC 15408-3 AGD_ADM.1.7C: The administrator guidance shall be consistent with all other 
documentation supplied for evaluation. 

The evaluator shall examine the administrator guidance to determine that it is consistent with all other 
documents supplied for evaluation. 
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The ST in particular may contain detailed information on any warnings to the TOE administrators with regard 
to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 

11.7.2.4.8 Work unit 2:AGD_ADM.1-8 

ISO/IEC 15408-3 AGD_ADM.1 .8C: The administrator guidance shall describe all security requirements for the 
IT environment that are relevant to the administrator. 

The evaluator shall examine the administrator guidance to determine that it describes all IT security 
requirements for the IT environment of the TOE that are relevant to the administrator. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare them with the administrator guidance to ensure that all security requirements of the 
ST that are relevant to the administrator are described appropriately in the administrator guidance. 

1 1 .7.3 Evaluation of User guidance (AGD.USR.I) 

11.7.3.1 Objectives 

The objectives of this sub-activity are to determine whether the user guidance describes the security functions 
and interfaces provided by the TSF and whether this guidance provides instructions and guidelines for the 
secure use of the TOE. 

11.7.3.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST; 
' b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures. 

11.7.3.3 Application notes 

There may be different user roles or groups defined in the ST that are recognised by the TOE and that can 
interact with the TSF. The capabilities of these roles and their associated privileges are described in the FMT 
class. Different user roles and groups should be taken into consideration by the user guidance. 

11.7.3.4 Action AGD_USR.1. IE 

11.7.3.4.1 Work unit 2:AGD_USR.1-1 

ISO/IEC 15408-3 AGD_USR.1 .10: The user guidance shall describe the funcVons and interfaces available to 
the non-administrative users of the TOE. 
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The evaluator shall examine the user guidance to determine that it describes the security functions and 
interfaces available to the non-administrative users of the TOE. 

The user guidance should contain an overview of the security functionality that is visible at the user interfaces. 

The user guidance should identify and describe the purpose of the security interfaces and functions. 

11.7.3.4.2 Workunit2:AGD_USR.1-2 

ISO/IEC 15408-3 AGD_USR.1.2C: The user guidance shall describe the use of user-accessible security 
functions provided by the TOE. 

The evaluator shall examine the user guidance to determine that it describes the use of user-accessible 
security functions provided by the TOE. 

The user guidance should identify and describe the behaviour and interrelationship of the security interfaces 
and functions available to the user. 

If the user is allowed to invoke a TOE security function, the user guidance provides a description of the 
interfaces available to the user for that function. 

For each interface and function, the user guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system call, menu selection, command button) ; 

b) describe the parameters to be set by the user and their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

11.7.3.4.3 Workunit2:AGD_USR.1-3 

ISO/IEC 15408-3 AGD_USR.1 .3C: The user guidance shall contain warnings about user-accessible functions 
and privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the user guidance to determine that it contains warnings aboi t user-accessible 
functions and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges in making use of the different 
functions of the TOE. This means that some users are authorised to perform certain functions, while other 
users may not be so authorised. These user-accessible functions and privileges are described by the user 
guidance. 

The user guidance should identify the functions and privileges that can be used, the types of commands 
required for them, and the reasons for such commands. The user guidance should contain warnings regarding 
the use of the functions and privileges that must be controlled. Warnings should address expected effects, 
possible side effects, and possible interactions with other functions and privileges. 

1 1 .7.3.4.4 Work unit 2:AGD_USR.1 -4 

ISO/IEC 15408-3 AGD_USR.1.4C: The userguidance shall clearly present all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

The evaluator shall examine the user guidance to determine that it presents all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 
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Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. IHowever, only the information that is of concern to the secure operation of the TOE 
need be included in the user guidance. 

The user guidance should provide advice regarding effective use of the security functions (e.g. reviewing 
password composition practices, suggested frequency of user file backups, discussion on the effects of 
changing user access privileges). 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

The user guidance should indicate whether the user can invoke a function or whether the user requires the 
assistance of an administrator. 

11.7.3.4.5 Workunit2:AGD_USR.1-S 

ISO/IEC 15408-3 AGD_USR.1.5C: The user guidance shall be consistent with all other documentation 
supplied for evaluation. 

The evaluator shall examine the user guidance to determine that it is consistent with all other documentation 
supplied for evaluation. 

The evaluator ensures that the user guidance and all other documents supplied for evaluation do not 
contradict each other. This is especially true if the ST contains detailed information on any warnings to the 
TOE users with regard to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 

11.7.3.4.6 Workunlt2:AGD_USR.1-6 

ISO/IEC 15408-3 AGD„USR.1.6C: The user guidance shall describe all security recfuimments for the IT 
environment that are relevant to the user 

The evaluator shall examine the user guidance to determine that it describes all security requirements fpr the 
IT environment of the TOE that are relevant to the user. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare that with the user guidance to ensure that all security requirements of the ST, that are 
relevant to the user, are described appropriately in the user guidance. 

11.8 Teste activity 

The purpose of this activity is to determine, by independently testing a subset of the TSF, whether the TSF 
behaves as specified in the design documentation and in accordance with the TOE security functional 
requirements specified in the ST. 

11.8.1 Application notes 

The evaluator analyses the developer's tests to determine the extent to which they are sufficient to 
demonstrate that security functions perform as specified, and to understand the developer's approach to 
testing. The evaluator also executes a subset of the developer's tests as documented to gain confidence in 
the developer's test results. The evaluator will use the results of this analysis as an input to independently 
testing a subset of the TSF. With respect to this subset, the evaluator's tests take a testing approach that is 
different from that of the developer's tests, particularly if the developer's tests have shortcomings. 
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Other factors affecting the size and composition of the evaluator's test subset are discussed in the 
independent testing {ATE_IND.2 Independent testing - sample) sub-activity. One such factor affecting the 
composition of the subset is Known public domain weaknesses, Information about which the evaluator needs 
access (e.g. from a scheme). 

To determine the adequacy of developer's test documentation or to create new tests, the evaluator needs to 
understand the desired expected behaviour of a security function in the context of the requirements it is to 
satisfy. The evaluator may choose to focus on one security function of the TSF at a time, examining the ST 
requirement and the relevant parts of the functional specification and guidance documentation to gain an 
understanding of the way the TOE is expected to behave. 

11.8.2 Evaluation of Coverage (ATE_C0V.1) 

11.8.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer's test coverage evidence shows 
correspondence between the tests identified in the test documentation and the functional specification. 

11.8.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the functional specification; 

b) the test documentation; 

c) the test coverage evidence. 

11.8.2.3 Application notes 

The coverage analysis provide by the developer is required to show the correspondence between the test 
provided as evaluation evidence and the functional specification. However, the coverage analysis need not 
demonstrate that all security functions have been tested, or that all external interfaces to the TSF have been 
tested. Such shortcomings are considered by the evaluator during the independent testing (ATE_IND.2 
Independent testing - sample) sub-activity. 

1 1 .8.2.4 Action ATE_C0V.1 .1 E 

11.8.2.4.1 Workunlt2:ATE_COV.1-1 

ISO/IEC 15408-3 ATE_C0V.1.1C: The evidence of the test coverage shall show the correspondence between 
the tests identified in the test documentation and the TSF as described in the functional specification. 

The evaluator shall examine the test coverage evidence to determine that the correspondence between the 
tests identified in the test documentation and the functional specification is accurate. 

Correspondence may take the form of a table or matrix. The rajvecage evidence required for this component 
will reveal the extent of coverage, rather than to show complete coverage. In cases where coverage is shown 
to be poor the evaluator should increase the level of independent testing to compensate. 

Figure 8 displays a conceptual framework of the correspondence between security functions described in the 
functional specification and the tests outlined in the test documentation used to test them. Tests may involve 
one or multiple security functions depending on the test dependencies or the overall goal of the test being 
performed. 

The identification of the tests and the security functions presented in the test coverage evidence should be 
unambiguous, providing a clear correspondence between the identified tests and the functional specification 
of the security functions tested. 
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Figure 8 - A conceptual framework of the test coverage evidence 

In Figure 8 SF-3 does not have tests attributed to it; therefore, coverage with respect to the functional 
specification is incomplete. Incomplete coverage, however, will not impact the verdict of this sub-activity as the 
coverage evidence does not have to show complete coverage of the security functions identified in the 
functional specification. 

11.8.3 Evaluation of Functional tests (ATE_FUN.1) 

11.8.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer's functional test documentation is 
sufficient to demonstrate that security functions perform as specified. 

11.8.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the test documentation; 

d) the test procedures. 
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1 1 .8.3.3 Application notes 



The extent to which the test documentation is required to cover the TSF is dependent upon the coverage 
assurance component. 

For the developer tests provided, the evaluator determines whether the tests are repeatable, and the extent to 
which the developer's tests can be used for the evaluator's independent testing effort. Any security function for 
which the developer's test results indicate that it may not perform as specified should be tested independently 
by the evaluator to determine whether or not it does. 

The test documentation will identify any instances where privileged modes are used to set up test 
conditions/cleanup for further tests. The test documentation will describe why it was necessary to use 
privileged modes to obtain the necessary conditions (e.g. efficiency of the test harness, to generate specific 
objects required for a test that unprivileged users are unable to create) and also how the privileged modes are 
exited prior to the conduct of the test steps demonstrating the security functionality of the TOE. Therefore, 
although the test configuration may be inconsistent with the TOE as described in the ST during the 
establishment of the test conditions the test documentation will describe how the configuration is returned to a 
state that is consistent with the configuration described in the ST for the conduct of the test steps. 

11.8.3.4 Action ATE_FUN.1. IE 

1 1 .8.3.4.1 Work unit 2:ATE_FUN.1-1 

tSO/lEC 15408-3 ATE_FUN.1.1C: The test documentation stiall consist of test plans, test procedure 
descriptions, expected test results and actual test results. 

The evaluator shall check that the test documentation includes test plans, test procedure descriptions, 
expected test results and actual test results. 

11.8.3.4.2 Work unit 2:ATE_FUN.1-2 

ISO/IEC 1 5408-3 ATE_FUN.1 .2C: The test plans shall identify the security functions to be tested and describe 
the goal of the tests to be performed. 

The evaluator shall check that the test plan identifies the security functions to be tested. 

One method that could be used to identify the security function to be tested is a reference to the appropriate 
part(s) of the functional specification that specifies the particular security function. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

11.8.3.4.3 Work unit 2:ATE_FUN.1-3 

The evaluator shall examine the test plan to determine that it describes the goal of the tests performed. 

The test plan provides information about how the security functions are tested and the test configuration in 
which testing occurs. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

11.8.3.4.4 Work unit 2:ATE_FUN.1-4 

The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the 
configuration identified for evaluation in the ST. 
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The TOE referred to in the developer's test plan should have the same unique reference as established by the 
CM capabilities (ACM_CAP).* sub-activity. 

it is possible for the ST to specify more than one configuration for evaluation. The TOE may be composed of a 
number of distinct hardv/are and software implementations that need to be tested in accordance with the ST. 
The evaluator verifies that there are test configurations identified in the developer test documentation that ate 
consistent with each evaluated configuration described in the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

11.8.3.4.5 Workunit2:ATE_FUN.1-5 

The evaluator shall examine the test plan to determine that it is consistent with the test procedure descriptions. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A.3, Consistency 
analysis. 

11.8.3.4.6 Work unit2:ATE_FUN.1-8 

tSO/lEC 1 5408-3 ATE_FUN.1 .3C: The test procedure descriptions stiall identify the tests to be peiformed and 
describe the scenarios for testing each security function. These scenarios shall include any ordering 
dependencies on the results of other tests. 

The evaluator shall check that the test procedure descriptions identify each security function behaviour to be 
tested. 

One method that may be used to identify the security function behaviour to be tested is a reference to the 
appropriate part(s) of the design specification that specifies the particular behaviour to be tested. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

1 1 .8.3.4.7 Work unit 2: ATE_FUN.1 -7 

The evaluator shall examine the test procedure descriptions to determine that sufficient instructions are 
provided to establish reproducible initial test conditions including ordering dependencies if any. 

Some steps may have to be performed to establish initial conditions. For example, user accounts need to be 
added before they can be deleted. An example of ordering dependencies on the results of other tests is the 
need to test the audit function before relying on it to produce audit records for another security mechanism 
such as access control. Another example of an ordering dependency would be where one test case generates 
a file of data to be used as input for another test case. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

11.8.3.4.8 Work unit 2:ATE_FUN.1-8 

The evaluator shall examine the test procedure descriptions to determine that sufficient instructions are 
provided to have a reproducible means to stimulate the security functions and to observe their behaviour. 
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Stimulus is usually provided to a security function externally through the TSFI. Once an input (stimulus) is 
provided to the TSFI, the behaviour of the security function can then be observed at the TSFI. Reproducibility 
is not assured unless the test procedures contain enough detail to unambiguously describe the stimulus and 
the behaviour expected as a result of this stimulus. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

11.8.3.4.9 Workunlt2:ATE_FUN.1-9 

The evaluator shall examine the test procedure descriptions to determine that they are consistent with the test 
procedures. 

If the test procedure descriptions are the test procedures, then this work unit is not applicable and is therefore 
considered to be satisfied. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A.3, Consistency 
analysis. 

11.8.3.4.10 Work unit2:ATE„FUN.1-10 

ISO/IEC 15408-3 ATE_FUN.1.4C: The expected test results shall show the anticipated outputs from a 
successful execution of the tests. 

The evaluator shall examine the test documentation to determine that sufficient expected tests results are 
included. 

The expected test results are needed to determine whether or not a test has been successfully performed. 
Expected test results are sufTicient if they are unambiguous and consistent with expected behaviour given the 
testing approach. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

11.8.3.4.11 Work unit2:ATE_FUN.1-11 

ISO/IEC 1 5408-3 ATE_FUN. 1 .5C: The test results from the developer execution of the tests shall demonstrate 
that each tested security function behaved as specified. 

The evaluator shall check that the expected test results in the test documentation are consistent with the 
actual test results provided. 

A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies 
between the results. 

It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has 
been Virst performed. In such cases, the developer's test documentation should describe the process to 
reduce or synthesize the actual data. 

For example, the developer may need to test the contents of a message buffer after a network connection has 
occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary 
number would have to be converted to another form of data representation In order to make the test more 
meaningful. The conversion of this binary representation of data Into a higher-level representation will have to 
be described by the developer in enough detail to allow an evaluator to perform the conversion process (i.e. 
synchronous or asynchronous transmission, number of stop bits, parity, etc.). 
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It should be noted that the description of the process used to reduce or synthesize the actual data is used by 
the evaluator not to actually perform the necessary modification but to assess whether this process is correct. 
It is up to the developer to transform the expected test results into a format that allows an easy comparison 
with the actual test results. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A. 2, Sampling. 

If the expected and actual test results for any test are not the same, then a demonstration of the correct 
operation of a security function has not been achieved. Such an occurrence will influence the evaluator's 
independent testing effort to include testing the implicated security function. The evaluator should also 
consider increasing the sample of evidence upon which this work unit is performed. 

1 1 .8.3.4.1 2 Work unit 2:ATE_FUN.1 -12 

The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and 
results. 

The developer testing information recorded in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing of the TOE by the developer. The intent of providing this 
information is to give a meaningful overview of the developer testing effort. It is not intended that the 
information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of 
individual tests. The intention is to provide enough detail to allow other evaluators and overseers to gain some 
insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the 
overall results of the developer testing. 

Information that would typically be found in the ETR subclause regarding the developer testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested; 

b) testing approach. An account of the overall developer testing strategy employed; 

c) amount of developer testing performed. A description on the extent of coverage and depth of developer 
testing; 

d) testing results. A description of the overall developer testing results. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the developer testing effort. 

11.8.4 Evaluation of independent testing (ATEJND.2) 

11.8.4.1 Objectives 

The goal of this activity is to determine, by independently testing a subset of the TSF, whether the TOE 
behaves as specified, and to gain confidence in the developer's test results by performing a sample of the 
developer's tests. 

11.8.4.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 
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d) the administrator guidance; 

e) the secure installation, generation, and start-up procedures; 

f) the test documentation; 

g) the test coverage analysis; 
h) the depth of testing analysis; 
i) the TOE suitable for testing . 
1 1 .8.4.3 Action ATE JND.2.1 E 

11.8.4.3.1 Work unit 2:ATEJND.2-1 

ISO/IEC 15408-3 ATEJND.2.1C: The TOE shall be suitable for testing. 

The evaluator shall examine the TOE to determine that the test configuration is consistent with the 
configuration under evaluation as specified in the ST. 

The TOE used for evaluator testing should have the same unique reference as established by the CM 
capabilities (ACM_CAP).* sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation.The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator's TOE test configurations should be consistent with each evaluated configuration described in 
the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that 
these resources are calibrated correctly. 

1 1 .8.4.3.2 Work unit 2:ATEJND.2-2 

The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state 

It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous 
successful completion of the AD0JGS.1 Installation, generation, and start-up procedures sub-activity will 
satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed 
properly and is in a known state. If this is not the case, then the evaluator should follow the developer's 
procedures to install, generate and start up the TOE, using the supplied guidance only. 

If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work 
unit when successfully completed could satisfy work unit AD0_IGS.1-2, 

1 1 .8.4.3.3 Work unit 2: ATE JND.2-3 

ISO/IEC 15408-3 ATE_IND.2.2C: The developer shall provide an equivalent set of resources to those that 
were used in the developer's functional testing of the TSF. 

The evaluator shall examine the set of resources provided by the developer to determine that they are 
equivalent to the set of resources used by the developer to functionally test the TSF 
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The resource set may include laboratory access and special test equipment, among others. Resources that 
are not identical to those used by the developer need to be equivalent in terms of any impact they may have 
on test results. 

1 1 .8.4.4 Action ATEJND.2.2E 

1 1 .8.4.4.1 Worlt unit 2:ATE JND.2-4 

The evaluator shall devise a test subset 

The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing 
strategy would be to have the test subset contain as many security functions as possible tested with little 
rigour. Another testing strategy would be to have the test subset contain a few security functions based on 
their perceived relevance and rigorously test these functions. 

Typically the testing approach taken by the evaluator should fall somewhere between these two extremes. 
The evaluator should exercise most of the security functional requirements identified in the ST using at least 
one test, but testing need not demonstrate exhaustive specification testing. 

The evaluator, when selecting the subset of the TSF to be tested, should consider the following factors: 

a) The developer test evidence. The developer test evidence consists of: the test coverage analysis, the 
depth of testing analysis, and the test documentation. The developer test evidence will provide insight as 
to how the security functions have been exercised by the developer during testing. The evaluator applies 
this information when developing new tests to independently test the TOE. Specifically the evaluator 
should consider: 

1) augmentation of developer testing for specific security function(s). The evaluator may wish to perform 
more of the same type of tests by varying parameters to more rigorously test the security function. 

2) supplementation of developer testing strategy for specific security function(s). The evaluator may 
wish to vary the testing approach of a specific security function by testing it using another test 
strategy. 

b) The number of security functions from which to draw upon for the test subset. Where the TOE includes 
only a small number of security functions, it may be practical to rigourously test all of the security 
functions. For TOEs with a large number of security functions this will not be cost-effective, and sampling 
is required. 

c) Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be 
commensurate with that expended on any other evaluation activity. 

The evaluator selects the security functions to compose the subset. This selection will depend on a number of 
factors, and consideration of these factors may also influence the choice of test subset size: 

a) Rigour of developer testing of the security functions. All security functions identified in the functional 
specification had to have developer test evidence attributed to them as required by ATE_C0V.2 Analysis 
of coverage. Those security functions that the evaluator determines require additional testing should be 
included in the test subset. 

b) Developer test results. If the results of developer tests cause the evaluator to doubt that a security 
function, or aspect thereof, operates as specified, then the evaluator should include such security 
functions in the test subset. 

c) Known public domain weaknesses commonly associated with the type of TOE (e.g. operating system, 
firewall). Know public domain weaknesses associated with the type of TOE will influence the selection 
process of the test subset. The evaluator should include those security functions that address known 
public domain weaknesses for that type of TOE in the subset (know public domain weaknesses in this 
context does not refer to vulnerabilities as such but to inadequacies or problem areas that have been 
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experienced with this particular type of TOE). If no such weaknesses are known, then a more general 
approach of selecting a broad range of security functions may be more appropriate. 

d) Significance of security functions. Those security functions more significant than others in terms of the 
security objectives for the TOE should be included in the test subset. 

e) SOF claims made in the ST. All security functions for which a specific SOF claim has been made should 
be included in the test subset. 

f) Complexity of the security function. Complex security functions may require complex tests that impose 
onerous requirements on the developer or evaluator, which will not be conducive to cost-effective 
evaluations. Conversely, complex security functions are a likely area to find errors and are good 
candidates for the subset. The evaluator will need to strike a balance between these considerations. 

g) Implicit testing. Testing some security functions may often implicitly test other security functions, and their 
inclusion in 1he subset may maximize the number of security functions tested (albeit implicitly). Certain 
interfaces will typically be used to provide a variety of security functionality, and will tend to be the target 
of an effective testing approach. 

h) Types of interfaces to the TOE (e.g. programmatic, command-line, protocol). The evaluator should 
consider including tests for all different types of interfaces that the TOE supports. 

i) Functions that are innovative or unusual. Where the TOE contains innovative or unusual security 
functions, which may feature strongly in marketing literature, these should be strong candidates for 
testing. 

This guidance articulates factors to consider during the selection process of an appropriate test subset, but 
these are by no means exhaustive. 

For guidance on sampling see A.2, Sampling. 

1 1 .8.4.4.2 Work unit 2:ATEJND.2-5 

The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the 
tests to be reproducible 

With an understanding of the expected behaviour of a security function, from the ST and the functional 
specification, the evaluator has to determine the most feasible way to test the function. Specifically the 
evaluator considers: 

a) the approach that will be used, for instance, whether the security function will be tested at an external 
interface, at an internal interface using a test harness, or will an alternate test approach be employed (e.g. 
in exceptional circumstances, a code inspection); 

b) the security function interface(s) that will be used to stimulate the security function and observe 
responses; 

c) the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need 
to exist and security attributes they will need to have); 

d) special test equipment that will be required to either stimulate a security function (e.g. packet generators) 
or make observations of a security function (e.g. network analysers). 

The evaluator may find it practical to test each security function using a series of test cases, where each test 
case will test a very specific aspect of expected behaviour. 

The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant 
design specification, and to the ST, if necessary. 
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1 1 .8.4.4.3 Work unit 2:ATEJND.2-6 

The evaluator shall conduct testing 

The evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test 
documentation is used as a basis for testing but this does not preclude the evaluator from performing 
additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TQE discovered 
during testing. These new tests are recorded in the test documentation. 

11.8.4.4.4 Work unit 2:ATEJND.2-7 

The evaluator shall record the following information about the tests that compose the test subset: 

a) identification of the security function behaviour to be tested; 

b) instructions to connect and setup all required test equipment as required to tx^nduct the test; 

c) instructions to establish all prerequisite test conditions; 

d) instructions to stimulate the security function; 

e) instructions for observing the behaviour of the security function; 

f) descriptions of all expected results and the necessary analysis to be perfonned on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE; 

h) actual test results. 

The level of detail should be such that another evaluator could repeat the tests and obtain an equivalent result. 
While some specific details of the test results may be different (e.g. time and date fields in an audit record) the 
overall result should be identical. 

There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. 
the actual test results of a test may not require any analysis before a comparison between the expected 
results can be made). The determination to omit this information is left to the evaluator, as is the justification. 

1 1 .8.4.4.5 Work unit 2:ATEJND.2-8 

The evaluator shall check that all actual test results are consistent with the expected test results 

Any differences in the actual and expected test results may indicate that the TOE does not -perform as 
specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require 
corrective maintenance to the TOE or test documentation and perhaps require re-running of Impacted tests 
and modifying the test sample size and composition. This determination is left to the evaluator, as is its 

justification. 

11.8.4.5 Action ATEJND.2.3E 
11.8.4.5.1 Work unit 2:ATE_IND.2-9 

The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures 

The overall aim of this work unit is to perform a sufficient number of the developer tests to confirm the validity 
of the developer's test results. The evaluator has to decide on the size of the sample, and the developer tests 
that will compose the sample. 
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Taking into consideration the overall evaluator effort for the entire tests activity, normally 20% of the 
developer's tests should be performed although this may vary according to the nature of the TOE, and the test 
evidence supplied. 

All the developer tests can be traced back to specific security function(s). Therefore, the factors to consider in 
the selection of the tests to compose the sample are similar to those listed for subset selection in work-unit 
ATE_IN0.2-4. Additionally, the evaluator may wish to employ a random sampling method to select developer 
testslo include In the sample. 

For guidance on sampling see A.2, Sampling. 

11.8.4.5.2 Wori( unit2:ATEJND.2-10 

The evaluator shall check that all the actual test results are consistent with the expected test results 

Inconsistencies between the developer's expected test results and actual test results will compel the evaluator 
to resolve the discrepancies. Inconsistencies encountered by the evaluator could be resolved by a valid 
explanation and resolution of the inconsistendes by the developer. 

If a satisfactory explanation or resolution can not be reached, the evaluator's confidence in the developer's 
test results may be lessened and it may even be necessary for the evaluator to increase the sample size, to 
regain confidence in the developer testing. If the increase in sample size does not satisfy the evaluator's 
concems, it may be necessary to repeat the entire set of deyeloper^s tests. Ultimately, to the extent that the 
TSF subset identified in work unit ATE_IND.2-4 is adequately tested, deficiencies with the developer's tests 
need to result in either corrective action to the developer's tests or in the production of new tests by the 
evaluator. 

11.8.4.5.3 Work unit 2:ATE JND.2-1 1 

The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, 
depth and results 

The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing activity during the evaluation. The intent of providing this 
information is to give a meaningful overview of the testing effort. It is not intended that the information 
regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. 
The intention is to provide enough detail to allow other evaluators and overseers to gain some insight about 
the testing approach chosen, amount of evaluator testing performed, amount of developer tests performed, 
TOE test configurations, and the overall results of the testing activity. 

Infomnation that would typically be found in the ETR subclause regarding the evaluator testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested. 

b) subset size chosen. The amount of security functions that were tested during the evaluation and a 
justification for the size. 

c) selection criteria for the security functions that compose the subset. Brief statements about the factors 
considered when selecting security functions for inclusion in the subset. 

d) security functions tested. A brief listing of the security functions that merited inclusion in the subset. 

e) developer tests perfomned. The amount of developer tests performed and a brief description of the criteria 
used to select the tests. 

f) verdict for the activity. The overall judgement on the results of testing during the evaluation. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the testing the evaluator performed during the evaluation. 
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11.9 Vulnerability assessment activity 

The purpose of the vulnerability assessment activity is to determine tne exploitability of flaws or weaknesses 
in the TOE in the intended environment. This determination is based upon analysis performed by the 
developer, and is supported by evaluator penetration testing. 

1 1 .9.1 Evaluation of Strength of TOE security functions (AVA_SOF.1) 

11.9.1.1 Objectives 

The objectives of this sub-activity are to determine whether SOF claims are made in the ST for all probabilistic 
or permutational mechanisms and whether the developer's SOF claims made in the ST are supported by an 
analysis that is correct. 

11.9.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the strength of TOE security functions analysis. 

11.9.1.3 Application notes 

SOF analysis is performed on mechanisms that are probabilistic or permutational in nature, such as password 
mechanisms or biometrics. Although cryptographic mechanisms are also probabilistic in nature and are often 
described in terms of strength, AVA_S0F.1 Strength of TOE security function evaluation ts not applicable to 
cryptographic mechanisms. For such mechanisms, the evaluator should seek scheme guidance. 

Although SOF analysis is performed on the basis of individual mechanisms, the overall determination of SOF 
is based on functions. Where more than one probabilistic or permutational mechanism is employed to provide 
a security function, each distinct mechanism must be analysed. The manner in which these mechanisms 
combine to provide a security function will determine the overall SOF level for that function. The evaluator 
needs design information to understand how the mechanisms work together to provide a function, and a 
minimum level for such information is given by the dependency on ADV_HLD.1 Descriptive high-level design. 
The actual design information available to the evaluator is determined by the EAL, and the available 
information should be used to support the evaluator's analysis when required. 

For a discussion on SOF in relation to multiple TOE domains see subclause Evaluation of IT security 
requirements (ASE_REQ.1). 

11.9.1.4 Action AVA_S0F.1. IE 

11.9.1.4.1 Workunit2:AVA_SOF.1-1 

ISO/IEC 15408-3 AVA_S0F.1.1C: For each mechanism with a strength of TOE security function claim the 
strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level 
defined in the PP/ST 

The evaluator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim In the ST expressed as a SOF rating. 
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If SOF claims are expressed solely as SOF metrics, then this work unit is not applicable and is therefore 
considered to be satisfied. 

A SOF rating is expressed as one of SOF-basic, SOF.medium or SOF-high, which are defined in terms of 
attack potential - refer to ISO/IEC 15408-1 clause 2. A minimum overall SOF requirement expressed as a 
rating applies to all non-cryptographic, probabilistic or permutationai security mechanisms. However, 
individual mechanisms may have a SOF claim expressed as a rating that exceeds the overall SOF 
requirement. 

Guidance on determining the attack potential necessary to effect an attack and, hence, to determine SOF as a 
rating is in A.8, Strength of function and vulnerability analysis. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

1 1 .9.1 .4.2 Work unit 2:AVA_S0F.1 -2 

ISO/IEC 15408-3 AVA_S0F.1.2C: For each mechanism with a spec/ffc strength of TOE security function claim 
the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of 
function metric defined in the PP/ST. 

The evaluator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim in the ST expressed as a metric. 

If SOF claims are expressed solely as SOF ratings, then this work unit is not applicable and is therefore 
considered to be satisfied. 

A minimum overall SOF requirement expressed as a rating applies to all non-cryptographic, probabilistic or 
permutationai mechanisms. However, individual mechanisms may have a SOF claim expressed as a metric 
that meets or exceeds the overall SOF requirement. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

11.91.4.3 Workunlt2:AVA_SOF.1-3 

The evaluator shall examine the SOF analysis to determine that any assertions or assumptions supporting the 
analysis are valid. 

For example, it may be a flawed assumption that a particular implementation of a pseudo-random number 
generator will possess the required entropy necessary to seed the security mechanism to which the SOF 
analysis is relevant. 

Assumptions supporting the SOF analysis should reflect the worst case, unless worst case is invalidated by 
the ST. Where a number of different possible scenarios exist, and these are dependent on the behaviour of 
the human user or attacker, the case that represents the lowest strength should be assumed unless, as 
previously stated, this case is invalid. 

For example, a strength claim based upon a maximum theoretical password space (i.e. all printable ASCII 
characters) would not be worst case because it is human behaviour to use natural language passwords, 
effectively reducing the password space and associated strength. However, such an assumption could be 
appropriate if the TOE used IT measures, identified in the ST, such as password filters to minimise the use of 
natural language passwords. 

11.9.1.4.4 Workunit2:AVA_SOF.1-4 

The evaluator shall examine the SOF analysis to determine that any algorithms, principles, properties and 
calculations supporting the analysis are correct. 

The nature of this work unit is highly dependent upon the type of mechanism being considered. A.8, Strength 
of function and vulnerability analysis, provides an example SOF analysis for an identification and 
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authentication function that is implemented using a password mechanism; the analysis constders the 
maximum password space to ultimately arrive at a SOF rating. For biometrics, Vne analysis shoukl consider 
resolution and other factors Impacting the mechanism's susceptibUity to spoofing. 

SOF expressed as a rating is based on the minimum attack potential required to defeat the security 
mechanism. The SOF ratings are defined in tenns of attack potential in ISO/IEC 15408-1 clause 2. 

For guidance on attack potential see A.8, Strength of function and vulnerability analysis. 

11 .9.1 .4.5 Work unit 2:AVA_SOF.1 -5 

The evaluator shall examine the SOF analysis to determine that each SOF claim is met or exceeded. 
For guidance on the rating of SOF claims see A.B, Strength of function and vulnerability analysis. 

11.9.1.4.6 Work unit 2:AVA_SOF.1^ 

The evaluator shall examine the SOF analysis to determine that all functions with a SOF claim meet the 
minimum strength level defined in the ST. 

11.9.1.5 Action AVA_S0F.1.2E 

11.9.1.5.1 Work unit 2:AVA_SOF.1-7 

The evaluator shall examine the functional specification, the high-level design, the low-level design, the user 
guidance and the administrator guidance to detemiine that all probabilistic or permutational mechanisms have 

a SOF claim. 

The Identification by the developer of security functions that are realised by probabilistic or permutational 
mechanisms is verified during the ST evaluation. However, because the TOE summary specification may 
have been the only evidence available upon which to perform that activity, the identification of such 
mechanisms may be incomplete. Additional evaluation evidence required as Input to this sub-activity may 
Identify additional probabilistic or permutational mechanisms not already identified in the ST. If so, the ST will 
have to be updated appropriately to reflect the additional SOF claims and the developer will need to provide 
additional analysis that justifies the claims as input to evaluator action AVA_S0F.1 .IE. 

1 1 .9.1 .5.2 Work unit 2:AVA_S0F.1 -8 

The evaluator shall examine the SOF claims to determine that they are con-ect. 

Where the SOF analysis includes assertions or assumptions (e.g. about how many authentication attempts 
are possible per minute), the evaluator should independently confirm that these are correct. This may be 
achieved through testing or through independent analysis. 

1 1 .9.2 Evaluation of Vulnerability analysis (AVA_VLA.1 ) 

11.9.2.1 Objectives 

The objective of this sub-activity is to determine whether the TOE, in its intended environment, has exploitable 
obvious vulnerabilities. 

11.9.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 
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c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the vulnerability analysis; 

h) the strength of function claims analysis; 

j) the TOE suitable for testing. 

Other input for this sub-activity is: 

a) current information regarding obvipus vulnerabilities (e.g. from an overseer). 

11.9.2.3 Application notes 

The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and 
the secure installation, generation, and start-up procedures. 

The consideration of exploitable vulnerabilities will be determined by the security objectives and functional 
requirements in the ST. For example, if measures to prevent bypass of the security functions are not required 
in the ST (TSF physical protection (FPT_PHP), Reference mediation (FPT_R\/M) and Domain separation 
(FPT_SEP) are absent) then vulnerabilities based on bypass should not be considered. 

Vulnerabilities may be in the public domain, or not, and may require skill to exploit, or not. These two aspects 
are related, but are distinct. It should not be assumed that, simply because a vulnerability is in the public 
domain, it can be easily exploited. 

The following terms are used in the guidance with specific meaning: 

a) Vulnerability - a weakness in the TOE that can be used to violate a security policy in some environment; 

b) Vulnerability analysis - A systematic search for vulnerabilities in the TOE, and an assessment of those 
found to determine their relevance for the intended environment for the TOE; 

c) Obvious vulnerability - a vulnerability that is open to exploitation that requires a minimum of 
understanding of the TOE, technical sophistication and resources; 

d) Potential vulnerability - A vulnerability the existence of which is suspected (by virtue of a postulated attack 
path), but not confirmed, in the TOE; 

e) Exploitable vulnerability - A vulnerability that can be exploited in the intended environment for the TOE; 

f) Non-exploitable vulnerability - A vulnerability that cannot be exploited in the intended environment for the 
TOE; 

g) Residual vulnerability - A non-exploitable vulnerability that could be exploited by an attacker with greater 
attack potential than is anticipated in the intended environment for the TOE; 

h) Penetration testing - Testing canied out to detennine the exptoitability of identified TOE potential 
vulnerabilities in the intended environment for the TOE. 
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11.9,2.4 Action AVA_VLA.1.1E 

11.9.2.4.1 Work unit 2:AVA_VI-A.1-1 

ISO/IEC 15408-3 AVA_VLA.1.1C: The vulnerability analysis documentation shall describe the analysis of the 
TOE deliverables performed to search for obvious ways in which a user can violate the TSP. 

ISO/IEC 15408-3 AVA_VLA.1.2C: The vulnerability analysis documentation shall describe the disposition of 
obvious vulnerabilities. 

ISO/IEC 15408-3 AVA_VLA.1.3C: The vulnerability analysis documentation shall show, for all identified 
vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. 

The evaluator shall examine the developer's vulnerability analysis to determine that the search for obvious 
vulnerabilities has considered all relevant information. 

The developer's vulnerability analysis should cover the developer's search for obvious vulnerabilities in at 
least all evaluation deliverables and public domain information sources. The evaluator should use the 
evaluation deliverables, not to perform an independent vulnerability analysis (not required at AVA_VLA.1 
Developer vulnerability analysis), but as a tiasis for assessing the developer's search for obvious 
vulnerabilities. 

Information in the public domain is highly dynamic. Therefore, it is possible that new vulnerabilities are 
reported in the public domain between the time the developer performs the vulnerability analysis and the time 
that the evaluation is completed. The point at which monitoring of the public domain information ceases is an 
evaluation authority issue; therefore guidance and agreement should be sought from the evaluation authority. 

11.9.2.4.2 Worl<unit2:AVA_VI_A.1-2 

The evaluator shall examine the developer's vulnerability analysis to determine that each obvious vulnerability 
is described and that a rationale is given for why it is not exploitable in the intended environment for the TOE. 

The developer is expected to search for obvious vulnerabilities, based on knowledge of the TOE, and of public 
domain information sources. Given the requirement to identify only obvious vulnerabilities, a detailed analysis 
ts not expected. The developer filters this information, based on the above definition, and shows that obvious 
vulnerabilities are not exploitable in the intended environment. 

The evaluator needs to be concerned with three aspects of the developer's analysis: 

a) whether the developer's analysis has considered all evaluation deliverables; 

b) whether appropriate measures are in place to prevent the exploitation of obvious vulnerabilities in the 
intended environment; 

c) whether some obvious vulnerabilities remain unidentified. 

The evaluator should not be concerned over whether identified vulnerabilities are obvious or not, unless this is 
used by the developer as a basis for determining non-exploitability. In such a case the evaluator validates the 
assertion by determining resistance to an attacker with low attack potential for the identified vulnerability. 

The concept of obvious vulnerabilities is not related to that of attack potential. The latter is determined by the 
evaluator during independent vulnerability analysis. Since this activity is not performed for AVA_VLA.1 
Developer vulnerability analysis, there is normally no searching and filtering by the evaluator on the basis of 
attack potential. However, the evaluator may still discover potential vulnerabilities during the evaluation, and 
the determination of how these should be addressed will be made by reference to the definition of obvious 
vulnerabilities and the concept of low attack potential. 

The determination as to whether some obvious vulnerabilities remain unidentified is limited to assessment of 
the validity of the developer's analysis, a comparison with available public domain vulnerability information, 
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and a comparison with any further vulnerabilities identified by the evaluator during the course of other 
evaluation activities. 

A vulnerability is termed non-exploitable if one or more of the following conditions exist: 

a) security functions or measures in the (IT or non-IT) environment prevent exploitation of the vulnerability in 
the intended environment. For Instance, restricting physical access to the TOE to authorised users only 
may effectively render a TOE's vulnerability to tampering unexploitable; 

b) the vulnerability is exploitable but only by attackers possessing moderate or high attack potential. For 
instance, a vulnerability of a distributed TOE to session hijack attacks requires an attack potential beyond 
that required to exploit an obvious vulnerability. However, such vulnerabilities are reported in the ETR as 
residual vulnerabilities. 

c) either the threat is not claimed to be countered or the violable organisational security policy is not claimed 
to be achieved by the ST. For instance, a firewall whose ST makes no availability policy claim and is 
vulnerable to TCP SYN attacks (an attack on a common Internet protocol that renders hosts incapable of 
servicing connection requests) should not fail this evaluator action on the basis of this vulnerability alone. 

For guidance on determining attack potential necessary to exploit a vulnerability see A.8, Strength of function 
and vulnerability analysis. 

11.9.2.4.3 Workunit2:AVA_VLA.1-3 

The evaluator shall examine the developer's vulnerability analysis to determine that it is consistent with the ST 
and the guidance. 

The developer's vulnerability analysis may address a vulnerability by suggesting specific configurations or 
settings for TOE functions. If such operating constraints are deemed to be effective and consistent with the ST, 
then all such configurations/settings should be adequately described in the guidance so that they may be 
employed by the consumer. 

11.9.2.5 Action AVA_VLA.1.2E 

11.9.2.5.1 Workunit2:AVA_VLA.1-4 

The evaluator shall devise penetration tests, building on the developer vulnerability analysis. 
The evaluator prepares for penetration testing: 

a) as necessary to attempt to disprove the developer's analysis in cases where the developer's rationale for 
why a vulnerability is unexploitable is suspect in the opinion of the evaluator; 

b) as necessary to determine the susceptibility of the TOE, in its intended environment, to an obvious 
vulnerability not considered by the developer. The evaluator should have access to current information 
(e.g. from the overseer) regarding obvious public domain vulnerabilities that may not have been 
considered by the developer, and may also have identified potential vulnerabilities as a result of 
performing other evaluation activities. 

The evaluator is not expected to test for vulnerabilities (including those in the public domain) beyond those 
which are obvious. In some cases, however, it will be necessary to carry out a test before the exploitability can 
be determined. Where, as a result of evaluation expertise, the evaluator discovers a vulnerability that is 
beyond obvious, this is reported in the ETR as a residual vulnerability. 

With an understanding of the suspected obvious vulnerability, the evaluator determines the most feasible way 
to test for the TOE's susceptibility. Specifically the evaluator considers: 

a) the security function interfaces that will be used to stimulate the TSF and observe responses; 
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b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to 
exist and security attributes they will need to have); 

c) special test equipment that will be required to either stimulate a security function or make observations of 
a security function (although it is unlikely that specialist equipment would be required to exploit an 
obvious vulnerability). 

The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where 
each test case will test for a specific obvious vulnerability. 

1 1 .9.2.5.2 Work unit 2:AVA_VLA.1-5 

The evaluator shall produce penetration test documentation for the tests that build upon the developer 
vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall 
include: 

a) identification of the obvious vulnerability the TOE is being tested for; 

b) instructions to connect and setup all required test equipment as required to conduct the penetration test; 

c) instructions to establish all penetration test prerequisite inifial conditions; 

d) instructions to stimulate the TSF; 

e) instructions for observing the behaviour of the TSF; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE. 

The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the 
tests and obtain an equivalent result. 

11.9.2.5.3 Work unit 2:AVA_VLA.1-6 

The evaluator shall conduct penetration testing, building on the developer vulnerability analysis. 

The evaluator uses the penetration test documentation resulting fi^om work unit AVA_VLA.1-4 as a basis for 
executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad 
hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learned 
during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test 
documentation. Such tests may be required to follow up unexpected results or observations, or tc investigate 
potential vulnerabilities suggested to the evaluator during the pre-planned testing. 

1 1 .9.2.5.4 Work unit 2:AVA_VU\.1 -7 

The evaluator shall record the actual results of the penetration tests. 

While some specific details of the actual test results may be different from those expected (e.g. time and date 
fields in an audit record) the overall result should be identical. Any differences should be justified. 

1 1.9.2.5.5 Work unit 2:AVA_ViJ\.1-8 

The evaluator shall examine the results of all penetration testing and the conclusions of all vulnerability 
analysis to determine that the TOE, in its intended environment, has no exploitable obvious vulnerabilities. 

If the results reveal that the TOE has obvious vulnerabilities, exploitable in its intended environment, then this 
results in a failed verdict for the evaluator action. 
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11.9.2.5.6 Workunit2:AVA VLA.1-9 



The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, 
configuration, depth and results. 

The penetration testing inforniation reported in the ETR allows the evaluator to convey the overall penetration 
testing approach and effort expended on this sub-activity. The intent of providing this information is to give a 
meaningful overview of the evaluator's penetration testing effort. It is not intended that the information 
regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual 
penetration tests. The intention is to provide enough detail to allow other evaluators and overseers to gain 
some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE 
test configurations, and the overall results of the penetration testing activity. 

Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts 
is: 

a) TOE test configurations. The particular configurations of the TOE that were penetration tested; 

b) security functions penetration tested. A brief listing of the security functions that were the focus of the 
penetration testing; 

c) verdict for the sub-activity. The overall judgement on the results of penetration testing. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the penetration testing the evaluator performed during the 
evaluation. 

11.9.2.5.7 Work unit 2:AVA_VLA.1 -10 

The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for 
each. 

a) its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the 
evaluator, read in a publication); 

b) the implicated security function(s), objective(s) not met, organisational security policy(ies) contravened 
and threat(s) realised; 

c) a description; 

d) whether it is exploitable in its intended environment or not (i.e. exploitable or residual); 

e) identification of evaluation party (e.g. developer, evaluator) who identified it. 

12 EAL3 evaluation 

12.1 Introduction 

EAL3 provides a moderate level of assurance. The security functions are analysed using a functional 
specification, guidance documentation, and the high-level design of the TOE to understand the security 
behaviour. The analysis is supported by independent testing of a subset of the TOE security functions, 
evidence of developer testing based on the functional specification and the high level design, selective 
confirmation of the developer test results, analysis of strengths of the functions, and evidence of a developer 
search for obvious vulnerabilities. Further assurance is gained through the use of development environment 
controls. TOE configuration management, and evidence of secure delivery procedures. 
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12.2 Objectives 

The objective of this clause is to define the minimal evaluation effort for achieving an EAL3 evaluation and to 
provide guidance on v»>ays and means of accomplishing the evaluation. 

12.3 EAL3 evaluation relationships 

An EAL3 evaluation covers the following: 

a) evaluation input task (Clause 7); 

b) EAL3 evaluation activities comprising the following: 

1) evaluation of the ST (Clause 9); 

2) evaluation of the configuration management (Subclause 12,4); 

3) evaluation of the delivery and operation documents (Subclause 12.5); 

4) evaluation of the development documents (Subclause 12.6); 

5) evaluation of the guidance documents (Subclause 12.7); 

6) evaluation of the life cycle support (Subclause 12.8); 

7) evaluation of the tests (Subclause 12.9); 

8) testing (Subclause 12.9); 

9) evaluation of the vulnerability assessment (Subclause 1 2.10); 

c) evaluation output task (Clause 7). 

The evaluation activities are derived from the EAL3 assurance requirements contained in ISO/IEC 15408-3. 

The ST evaluation is started prior to any TOE evaluation sub-activities since the ST provides the basis and 
context to perform these sub-activities. 

The sub-activities comprising an EAL3 evaluation are described in this clause. Although the sub-activities can, 
in general, be started more or less coincidentalty, some dependencies between sub-activities have to be 
considered by the evaluator. 

For guidance on dependencies see Annex A 

12.4 Configuration management activity 

The purpose of the configuration management activity is to assist the consumer In identifying the evaluated 
TOE, to ensure that configuration items are uniquely identified, and to ensure the adequacy of the procedures 
that are used by tKe developer to control and track changes that are made to the TOE. This includes details 
on what changes are tracked, and how potential changes are incorporated. 

12.4.1 Evaruation of CM capabilities (ACM_CAP.3) 

12.4.1.1 Objectives 

The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE and 
its associated configuration items, and whether the ability to modify these items is properly controlled. 
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12.4.1.2 Input 

The evaluation evidence for tliis sub-activity is: 

a) the ST; 

b) the TOE suitable for testing; 

c) the configuration management documentation. 

1 2.4.1 .3 Action ACM_CAP.3.1 E 

12.4.1.3.1 Work unit 3:ACM_CAP.3-1 

ISO/IEC 15408-3 ACM_CAP.3. 10: The reference for the TOE shall be unique to each version of the TOE. 

The evaluator shall check that the version of the TOE provided for evaluation Is uniquely referenced. 

The evaluator should use the developer's CM system to validate the uniqueness of the reference by checking 
the configuration list to ensure that the configuration items are uniquely identified. Evidence that the version 
provided for evaluation is uniquely referenced may be incomplete if only one version is examined during the 
evaluation, and the evaluator should look for a referencing system that is capable of supporting unique 
references (e.g. use of numbers, letters or dates). However, the absence of any reference will normally lead to 
a fail verdict against this requirement unless the evaluator is confident that the TOE can be uniquely identified. 

The evaluator should seek to examine more than one version of the TOE (e.g. during rework following 
discovery of a vulnerability), to check that the two versions are referenced differently. 

12.4.1 .3.2 Wori( unit 3:ACM_CAP.3-2 

ISO/IEC 15408-3 ACM_CAP.3.2C: The TOE shall be labelled with its reference. 

The evaluator shall check that the TOE provided for evaluation is labelled with its reference. 

The evaluator should ensure that the TOE contains a unique reference such that it is possible to distinguish 
different versions of the TOE. This could be achieved through labelled packaging or media, or by a label 
displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the 
TOE (e.g. at the point of purchase or use). 

The TOE may provide a method by which it can be easily identified. For example, a software TOE may display 
its name and version number during the start up routine, or in response to a command line entry. A hardware 
or firmware TOE may be identified by a part number physically stamped on the TOE. 

12.4.1.3.3 Worit unit 3:ACIW_CAP.3-3 

The evaluator shall check that the TOE references used are consistent. 

If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible 
to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. 
This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, 
that they have installed this version, and that they have the correct version of the guidance to operate the TOE 
in accordance with its ST. The evaluator can use the configuration list that is part of the provided CM 
documentation to verify the consistent use of identifiers. 

The evaluator also verifies that the TOE reference is consistent with the ST. 

For guidance on consistency analysis see A.3, Consistency analysis. 
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12.4.1.3.4 Work unit 3:ACM_CAP.3-4 

ISO/IEC 15408-3 ACM_CAP.3.3C: 7/)e CM documentation shall include a configuration list and a CM plan. 
The evaluator shall check thai the CM documentation provided includes a configuration list. 
A configuration list identifies the items being maintained under configuration control. 

12.4.1.3.5 Work unit 3:ACM_CAP.3-5 

The evaluator shall check that the CM documentation provided includes a CM plan. 

12.4.1.3.6 Work unit 3:ACM_CAP.3-6 

ISO/IEC 15408-3 ACM_CAP.3.4C: The configuration list shall uniquely identify all configuration items that 
compnse the TOE. 

The evaluator shall check that the configuration list uniquely identifies each configuration item. 

The configuration list contains a list of the configuration items that comprise the TOE, together with sufficient 
information to uniquely identify which version of each item has been used (typically a version number). Use of 
this list will enable the evaluator to check that the correct configuration items, and the correct version of each 
item, have been used during the evaluation. 

12.4.1.3.7 Work unit 3:ACr\fl_CAP.3-7 

ISO/IEC 15408-3 ACM_CAP.3.5C: The configuration list shall describe the configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration list to determine that it identifies the configuration items that 
comprise the TOE. 

The minimum scope of configuration items to be covered in the configuration list is given by CM scope 
(ACM_SCP). 

1 2.4.1 .3.8 Work unit 3:ACM_CAP.3-8 

ISO/IEC 1 5408-3 ACM_CAP.3.6C: The CM documentation shall describe the method used to uniquely identify 
the configuration items that comprise the TOE. 

The evaluator shall examine the method of identifying configuration items to determine that it describes how 
configuration items are uniquely identified. 

12.4.1.3.9 Work unit 3:ACIVI_CAP.3-9 

ISO/IEC 15408-3 ACM_CAP.3.7C: The CM system shall uniquely identify all configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration items to determine that they are identified in a way that is 
consistent with the CM documentation. 

Assurance that the CM system uniquely idenfifies all configurafion items is gained by examining the identifiers 
for the configuration items. For both configuration Items that comprise the TOE, and drafts t)f configuration 
Items that are submitted by the developer as evaluation evidence, the evaluator confirms that each 
configuration item possesses a unique identifier in a manner consistent with the unique identification method 
that is described in the CM documentation. 
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12.4.1.3.10 Work unit 3:ACM_CAP.3-10 

ISO/IEC 1 5408-3 ACM_CAP.3.8C: The CM plan shall describe how the CM system is used. 

The evaluator shall examine the CM plan to determine that It describes how the CM system Is used to 
maintain the integrity of the TOE configuration items. 

The descriptions contained in a CM plan may include: 

a) ail activities performed in the TOE development environment that are subject to configuration 
management procedures (e.g. creation, modification or deletion of a configuration item); 

b) the roles and responsibilities of individuals required to perform operations on individual configuration 
items (different roles may be identified for different types of configuration item (e.g. design documentation 
or source code)); 

c) the procedures that are used to ensure that only authorised individuals can make changes to 
configuration items; 

d) the procedures that are used to ensure that concurrency problems do not occur as a result of 
simultaneous changes to configuration items; 

e) the evidence that is generated as a result of application of the procedures. For example, for a change to a 
configuration item, the CM system might record a description of the change, accountability for the change, 
identification of all configuration items affected, status (e.g. pending or completed), and date and time of 
the change. This might be recorded in an audit trail of changes made or change control records; 

f) the approach to version control and unique referencing of TOE versions (e.g. covering the release of 
patches in operating systems, and the subsequent detection of their applicaWon). 

12.4.1.3.11 Work unit 3:ACM_CAP.3-11 

ISO/iEC 15408-3 AGM_CAP.3.9C: The evidence shall demonstrate that the CM system is operating in 
accordance with the CM plan. 

The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified 
by the CM plan. 

The output produced by the CM system should provide the evidence that the evaluator needs to be confident 
that the CM plan is being applied, and also that all configuration items are being maintained by the CM system 
as required by ACM_CAP.3.10C. Example output could include change control forms, or configuration item 
access approval forms. 

12.4.1.3.12 Work unit3:ACM_CAP.3-12 

The evaluator shall examine the evidence to determine that the CM system is being used as it is described in 
the CM plan. 

The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation 
that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier 
version) to confirm that all operations of the Cf^ system have been carried out in line with documented 
procedures. The evaluator confirms that the evidence includes all the information identified for that operation 
in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may 
choose to sample the evidence. 

For guidance on sampling see A.2, Sampling. 

Further confidence in the correct operation of the CM system and the effective maintenance of configuration 
items may be established by means of interview with selected development staff. In conducting such 
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interviews, the evaluator should aim to gain a deeper understanding of how the CM system Is used in practice 
as well as to confirm that the CM procedures are being applied as described In the CM documentation. Note 
that such interviews should complement rather than replace the examination of documentary evidence, and 
may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide 
scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from 
the CM plan and records alone. This Is one case where clarification may be necessary through interviews. 

It is expected that the evaluator will visit the development site in support of this activity. 

For guidance on site visits see AJ5, Site Visits. 

12.4.1.3.13 Work unit 3:ACM_CAP.3-13 

ISO/IEC 15408-3 ACM_CAP.3.10C: The CM documentation shall provide evidence that all configuration items 
have been and are being effectively maintained under the CM system. 

The evaluator shall check that the configuration items identified in the configuration list are being maintained 
by the CM system. 

The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should 
check that for each type of configuration item (e.g. high-level design or source code modules) contained in the 
configuration list there are examples of the evidence generated by the procedures described in the CM plan. 
In this case, the approach to sampling will depend upon the level of granularity used in the CM system to 
control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a 
different sampling strategy should be applied compared to the case in which there are only 5, or even 1 . The 
emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on 
the detection of any minor error. 

For guidance on sampling see A.2, Sampling. 

12.4.1.3.14 Work unit 3:ACM_CAP.3-14 

ISO/IEC 15408-3 ACM_CAP.3.11C: The CM system shall provide measures such that only authorised 
changes are made to the configuration items. 

The evaluator shall examine the CM access control measures described in the CM plan to determine that they 
are effective in preventing unauthorised access to the configuration items. 

The evaluator may use a number of methods to determine that the CM access control measures are effective. 
For example, the evaluator may exercise the access control measures to ensure that the procedures could not 
be bypassed. The evaluator may use the outputs generated by the CM system procedures and already 
examined as part of the work unit ACM_CAP.3-12. The evaluator may also witness a demonstration of the CM 
system to ensure that the access control measures employed are operating effectively. 

12.4.2 Evaluation of CM scope (ACM_SCP.1) 

12.4.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer performs configuration management 
on the TOE implementation representation, design, tests, user and administrator guidance, and the CM 
documentation. 

12.4.2.2 Input 

The evaluation evidence for this sub-activity is: 
a) the configuration item list. 
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12.4.2.3 Action ACM_SCP.1.1E 

12.4.2.3.1 Work unit 3:ACM_SCP.1-1 

ISO/IEC 15408-3 ACM_SCP.1.1C: The list of conriguration items sliall include the following: implementation 
representation and the evaluation evidence required by the assurance components in the ST. 

The evaluator shall check that the configuration item list includes the set of items required by ISO/IEC 15408. 

The list includes at least the following; 

a) the TOE implementation representation (i.e., the components or subsystems that compose the TOE). For 
a software-only TOE, the implementation representation may consist solely of source code; for a TOE 
that includes a hardware platform, the implementation representation may refer to a combination of 
software, firmware and a description of the hardware. 

b) the evaluation evidence required by the assurance components in the ST. 

12.5 Delivery and operation activity 

The purpose of the delivery and operation activity is to judge the adequacy of the documentation of the 
procedures used to ensure that the TOE is installed, generated, and started in the same way the developer 
intended it to be and that it is delivered without modification. This includes both the procedures taken while the 
TOE is in transit, as well as the initialisation, generation, and start-up procedures. 

12.5.1 Evaluation of Delivery (AD0_DEL.1) 

12.5.1.1 Objectives 

The objective of this sub-activity is to determine whether the delivery documentation describes all procedures 
used to maintain security of the TOE when distributing the TOE to the user's site. 

12.5.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the delivery documentation. 

12.5.1.3 Action AD0_DEL.1. IE 

12.5.1.3.1 Work unit 3:AD0_DEL.1-1 

ISO/IEC 15408-3 AD0_DEL.1.1C: The delivery documentation shall describe all procedures that are 
necessary to maintain security when distributing versions of the TOE to a user's site. 

The evaluator shall examine the delivery documentation to determine that it describes all procedures that are 
necessary to maintain security when distributing versions of the TOE or parts of it to the user's site. 

Interpretation of the term "necessary" will need to consider the nature of the TOE and information contained in 
the ST. The level of protection provided should be commensurate with the assumptions, threats, 
organisational security policies, and security objectives identified in the ST. In some cases these may not be 
explicitly expressed in relation to delivery. The evaluator should determine that a balanced approach has been 
taken, such that delivery does not present an obvious weak point in an othenwise secure development process. 

The delivery procedures describe proper procedures to determine the identification of the TOE and to 
maintain integrity during transfer of the TOE or its component parts. The procedures describe which parts of 
the TOE need to be covered by these procedures. It should contain procedures for physical or electronic (e.g. 
for downloading off the Internet) distribution where applicable. The delivery procedures refer to the entire TOE, 
including applicable software, hardware, firmware and documentation. 
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The emphasis in the delivery documentation is likely to be on measures related to integrity, as technical 
measures are required to be applied to maintain integrity during the TOE delivery. However, confidentiality 
and availability of the delivery will be of concern in the delivery of some TOEs; procedures relating to these 
aspects of the secure delivery should also be discussed in the procedures. 

The delivery procedures should be applicable across all phases of delivery from the production environment to 
the installation environment (e.g. packaging, storage and distribution). 

Standard commercial practice for packaging and delivery may be acceptable. This includes shrink wrapped 
packaging, a security tape or a sealed envelope. For the distribution, the public mail or a private distribution 
service may be acceptable. 

The suitability of the choice of the delivery procedures Is influenced by the TOE (e.g. whether it is software or 
hardware) and by the security objectives. In cases where the delivery procedures differ for different parts of 
the TOE, the totality of procedures are suitable to meet the overall security objectives. 

12.5.1.4 implied ^valuator action 

12.5.1.4.1 Workunit3:ADO_DEL.1-2 

ISO/IEC 15408-3 AD0_DEL.1.2D: The developer shall use the delivery pmcedufBS. 

The evaluator shall examine aspects of the delivery process to detennine that the delivery procedures are 
used. 

The approach taken by the evaluator to check the application of delivery procedures will depend on the nature 
of the TOE, and the delivery process itself. In addition to examination of the procedures themselves, the 
evaluator should seek some assurance that they are applied in practice. Some possible approaches are: 

a) a visit to the distribution site(s) where practical application of the procedures may be observed; 

b) examination of the TOE at some stage during delivery, or at the user's site (e.g. checking for tamper proof 
seals); 

c) observing that the process is applied in practice when the evaluator obtains the TOE through regular 
channels; 

d) questioning end users as to how the TOE was delivered. 

For guidance on site visits see A.5. Site Visits. 

It may be the case of a newly developed TOE that the delivery procedures have yet to be exercised, in these 
cases, the evaluator has to be satisfied that appropriate procedures and facilities are in place for future 
deliveries and that all personnel involved are aware of their responsibilities. The evaluator may request a "dry 
run" of a delivery if this is practical. If the developer has produced other similar products, then an examination 
of procedures in their use may be useful in providing assurance. 

12.5.2 Evaluation of Installation, generation and start-up (ADOJGS.1) 

12.5.2.1 Objectives 

The objective of this sub-activity is to determine whether the procedures and steps for the secure installation, 
generation, and start-up of the TOE have been documented and result in a secure configuration. 

12.5.2.2 Input 

The evaluation evidence for this sub-activity is: 
a) the administrator guidance; 
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b) the secure installation, generation, and start-up procedures; 

c) tlie TOE suitable for testing. 

12.5.2.3 Application notes 

The installation, generation, and start-up procedures refer to all installation, generation, and start-up 
procedures, regardless of whether they are performed at the user's site or at the development site that are 
necessary to progress the TOE to the secure configuration as desaibed in the ST. 

12.5.2.4 Action AD0JGS.1. IE 

12.5.2.4.1 Work unit 3:AD0JGS.1-1 

ISO/IEC 15408-3 AD0_IGS.1.1C: The installation, generation and start-up documentation shall describe all 
the steps necessary for secure installation, generation and start-up of the TOE. 

The evaluator shall check that the procedures necessary for the secure installation, generation and start-up of 
the TOE have been provided. 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

1 2.5.2.5 Action AD0JGS.1 .2E 

12.5.2.5.1 Work unit 3:ADOJGS.1-2 

The evaluator shall examine the provided installation, generation, and start-up procedures to determine that 
they describe the steps necessary for secure installation, generation, and start-up of the TOE. 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

The installation, generation, and start-up procedures may provide detailed information about the following: 

a) changing the installation specific security characteristics of entities under the control of the TSF; 

b) handling exceptions and problems; 

c) minimum system requirements for secure installation if applicable. 

In order to confirm that the installation, generation, and start-up procedures result in a secure configuration, 
the evaluator may follow the developer's procedures and may perform the activities that customers are usually 
expected to perform to install, generate, and start-up the TOE (if applicable to the TOE), using the supplied 
guidance documentation only. This work unit might be perfomried in conjunction with the ATEJND.1-2 work 
unit. 

12.6 Development activity 

The purpose of the development activity is to assess the design documentation in terms of its adequacy to 
understand how the TSF provides the security functions of the TOE. This understanding is achieved through 
examination of increasingly refined descriptions of the TSF design documentation. Design documentation 
consists of a functional specification (which describes the external interfaces of the TOE) and a high-level 
design {which describes the architecture of the TOE in terms of internal subsystems). There is also a 
representation correspondence (which maps representations of the TOE to one another in order to ensure 
consistency). 
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12.6.1 Application notes 

ISO/IEC 15408 requirements for design documentation are levelled by formality. ISO/IEC 1 5408. considers a 
document's degree of formality (that is, whether it is informal, semiformal or formal) to be hierarchical. An 
informal document is one that is expressed in a natural language. The methodology does not dictate the 
specific language that must be used; that issue is lelt for the scheme. The following paragraphs differentiate 
the contents of the different informal documents. 

An informal functional specification comprises a description the security functions (at a level similar to that of 
the TOE summary specification) and a description of the externally-visibfe interfaces to the TSF. For example, 
if an operating system presents the user with a means of self-identification, of creating files, of modifying or 
deleting files, of setting permissions defining what other users may access files, and of communicating with 
remote machines, its functional specification would contain descriptions of each of these functions. If there are 
also audit functions that detect and record the occurrences of such events, descriptions of these audit 
functions would also be expected to be part of the functional specification; while these functions are 
technically not directly invoked by the user at the external interface, they certainly are affected by what occurs 
at the user's external interface. 

An informal high-level desrgn is expressed in terms of sequences of actions that occur in each subsystem in 
response to stimulus at its interface. For example, a firewall might be composed of subsystems that deal with 
packet filtering, with remote administration, with auditing, and with connection-level filtering. The high-level 
design description of the firewall would describe the actions that are taken, in terms of what actions each 
subsystem takes when an incoming packet arrives at the firewall. 

Informality of the demonstration of correspondence need not be in a prose form; a simple two-dimensional 
mapping may be sufficient. For example, a matrix with modules listed along one axis and subsystems listed 
along the other, with the cells identifying the correspondence of the two, would serve to provide an adequate 
informal correspondence between the high-level design and the low-level design. 

12.6.2 Evaluation of Functional specification (ADV_FSP.1) 

12.6.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has provided an adequate description 
of the security functions of the TOE and whether the security functions provided by the TOE are sufficient to 
satisfy the security functional requirements of the ST, 

12.6.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance. 

12.6.2.3 Action ADV_FSP.1. IE 

12.6.2.3.1 Work unit 3:ADV_FSP.1-1 

ISO/IEC 15408-3 ADV_FSP.1.1C: The functional specification stiall describe the TSF and its external 
interfaces using an infomial style. 

The evaluator shall examine the functional specification to determine that it contains all necessary infomrial 
explanatory text. 
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If the entire functional specification is informal, this work unit is not applicable and is therefore considered to 
be satisfied. 

Supporting narrative descriptior>s are necessary for those portions of the functional specification that are 
difficult to understand only from the semiformal or formal description (for example, to make clear the meaning 
of any formal notation). 

1 2.6.2.3.2 Work unit 3:ADV_FSP.1 -2 

ISO/IEC 15408-3 ADV_FSP.1.2C: The functional specification stiallbe internally consistent. 

The evatuator shall examine the functional specification to determine that it Is internally consistent. 

The evaluator validates the functional specification by ensuring that the descriptions of the interfaces making 
up the TSFI are consistent with the descriptions of the functions of the TSF 

12.6.2.3.3 Work unit 3:ADV_FSP.1-3 

ISO/IEC 15408-3 ADV_FSP.1.3C: The functional specification shall describe the purpose and method of use 
of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. 

The evaluator shall examine the functional specification to determine that it identifies all of the external TOE 
security function interfaces. 

The term external refers to that which is visible to the user. External interfaces to the TOE are either direct 
interfaces to the TSF or interfaces to non-TSF portions of the TOE. However, these non-TSF interfaces might 
have eventual access to the TSF. These external interfaces that directly or indirectly access the TSF 
collectively make up the TOE security function interface (TSFI). Figure 6 shows a TOE with TSF (cross- 
hatched) portions and non-TSF (empty) portions. This TOE has three external interfaces: interface c is a direct 
interface to the TSF; interface b is an indirect interface to the TSF; and interface a is an interface to non-TSF 
portions of the TOE. Therefore, interfaces b and c make up the TFSI. 




TOE 



Figure 9 - TSF Interfaces 

It should be noted that all security functions reflected in the functional requirements of ISO/IEC 15408-2 (or in 
extended components thereof) wilt have some sort of externally-visible manifestation. While not all of these 
are necessarily interfaces from which the security function can be lested, they are all externally-visible to 
some extent and must therefore be included in the functional specification. 
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12.6.2.3.4 Workunit3:ADV_FSP.1-4 

The evaluator shall examine the functional specification to determine that it describes all of the external TOE 
security function interfaces. 

For a TOE that has no threat of malicious users (i.e. TSF physical protection (FPT_PHP). Reference 
mediation (FPT_RVM), and Domain separation (FPT_SEP) are rightfully excluded from its ST), the only 
interfaces that are described in the functional specification (and expanded upon in the other TSF 
representation descriptions) are those to and from the TSF. The absence of TSF physical protection 
(FPT_PHP). Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) presumes there is no 
concern for any sort of bypassing of the security features; therefore, there is no concern with any possible 
impact that other interfaces might have on the TSF. 

On the other hand, if the TOE has a threat of malicious users or bypass (i.e. TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) are included in its ST), all 
external interfaces are described in the functional specification, but only to the extent that the effect of each is 
made clear: interfaces to the security functions (i.e. interfaces b and c In Figure 6) are completely described, 
while other interfaces are described only to the extent that it is clear that the TSF is inaccessible through the 
interface (i.e. that the interface is of type a, rather than b in Figure 6). The Inclusion of TSF physical protection 
(FPT_PHP). Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) Implies a concern that all 
interfaces might have some effect upon the TSF. Because each external interface is a potential TSF interface, 
the functional specification must contain a description of each interface in sufficient detail so that an evaluator 
can determine whether the interface is security relevant. 

Some architectures tend themselves to readily provide this interface description in sufficient detail for groups 
of external interfaces. For example, a kernel architecture is such that all calls to the operating system are 
handled by kernel programs; any calls that might violate the TSP must be called by a program wit*-- the 
privilege to do so. All programs that execute with privilege must be included in the functional specification. Any 
program external to the kernel that executes without privilege is incapable of affecting the TSP (i.e. such 
programs are interfaces of type a, rather than b in Figure 6) and may, therefore, be excluded from the 
functional specification. It is worth noting that, while the evaluator's understanding of the interface description 
can be expedited in cases where there is a kernel architecture, such an architecture is not necessary. 

12.6.2.3.5 Work unit 3:ADV_FSP.1-5 

The evaluator shall examine the presentation of the TSFI to detemiine that it adequately and correctly 
describes the behaviour of the TOE at each external interface describing effects, exceptions and error 
messages. 

In order to assess the adequacy and correctness of an interface's presentation, the evaluator uses the 
functional specification, the TOE summary specification of the ST, and the user and administrator guidance to 
assess the following factors: 

a) All security relevant user input parameters (or a characterisation of those parameters) should be identified. 
For completeness, parameters outside of direct user control should be identified if they are usable by 
administrators. 

b) All security relevant behaviour described in the reviewed guidance should be reflected in the description 
of semantics in the functional specification. This stiould include an identification of the behaviour in temis 
of events and the effect of each event. For example, if an operating system provides a rich file system 
interface, where it provides a different error code for each reason why a file is not opened upon request 
(e.g. access denied, no such file, file is in use by another user, user is not authorised to open the file after 
5pm, etc.), the functional specification should explain that a file is either opened upon request, or else that 
an error code is returned. (While the functional specification may enumerate all these different reasons for 
errors, it need not provide such detail.) The description of the semantics should include how the security 
requirements apply to the interface (e.g. whether the use of the interface is an auditable event and, if so, 
the information that can be recorded). 
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c) All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, 
the description of the interface should explain how the interface behaves in the presence or absence of 
privilege. 

d) The information contained in the descriptions of the security relevant parameters and syntax of the 
interface should be consistent across all documentation. 

Verification of the above is done by reviewing the functional specification and the TOE summary specrfication 
of the ST, as well as the user and administrator guidance provided by the developer. For example, if the TOE 
were an operating system and its underlying hardware, the evaluator would look for discussions of user- 
accessible programs, descriptions of protocols used to direct the activities of programs, descriptions of user- 
accessible databases used to direct the activities of programs, and for user interfaces (e.g. commands, 
application program interfaces) as applicable to the TOE under evaluation; the evaluator would also ensure 
that the processor instruction set is described. 

This review might be iterative, such that the evaluator would not discover the functional specification to be 
incomplete until the design, source code, or other evidence is examined and found to contain parameters or 
error messages that have been omitted from the functional specification. 

12.6.2.3.6 Work unit 3:ADV_FSP.1-6 

ISO/IEC 1 5408-3 ADV_FSP.1 .40: The functional specification stiall completely represent the TSF. 

The evaluator shall examine the functional specification to determine that the TSF is fully represented. 

In order to assess the completeness of the TSF representation, the evaluator consults the TQE summary 
specification of the ST, the user guidance, and the administrator guidance. None of these should describe 
security functions that are absent from the TSF presentation of the functional specification. 

12.6.2.4 Action AD V_FSP.1.2E 

1 2.6.2.4.1 Work unit 3:ADV_FSP.1 -7 

The evaluator shall examine the functional specification to determine that it is a complete instantiation of the 
TOE security functional requirements. 

To ensure that all ST security functional requirements are covered by the functional specification, the 
evaluator may construct a map between the TOE summary specification and the functional specification. Such 
a map might be already provided by the developer as evidence for meeting the correspondence 
(Representation correspondence (ADV_RCR).*) requirements, in which case the evaluator need only verify 
the completeness of this mapping, ensuring that all security functional requirements are mapped onto 
applicable TSFI presentations in the functional specification. 

12.6.2.4.2 Work unit 3:ADV_FSP.1-8 

The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the 
TOE security functional requirements. 

For each interface to a security function with specific characteristics, the detailed information in the functional 
specification must be exactly as it is specified in the ST. For example, if the ST contains user authentication 
requirements that the password length must be eight characters, the TOE must have eight-character 
passwords; if the functional specification describes six-character fixed length passwords, the functional 
specification would not be an accurate instantiation of the requirements. 

For each interface in the functional specification that operates on a controlled resource, the evaluator 
determines whether it returns an error code that indicates a possible failure due to enforcement of one of the 
security requirements; if no error code is returned, the evaluator determines whether an error code should be 
returned. For example, an operating system might present an interface to OPEN a controlled object. The 
description of this interface may include an error code that indicates that access was not authorised to the 
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object. If such an error code does not exist, the evaluator should confirm that this is appropriate (because, 
perhaps, access mediation is performed on READs and WRITES, rather than on OPENs). 

12.6.3 Evaluation of High-level design (ADV_HLD.2) 

12.6.3.1 Objectives 

The objective of this sub-activity is to determine whether the high-level design provides a description of the 
TSF in terms of major structural units (i.e. subsystems), provides a description of the interfaces to these 
structural units, and is a correct realisation of the functional specification. 

12.6.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design. 

12.6.3.3 Action ADV_HLD.2.1E 

12.6.3.3.1 Work unit 3:ADV_HLD.2-1 

ISO/IEC 15408-3 ADV_HLD.2.1C: The presentation of the high-level design shall be informal. 

The evaluator shall examine the high-level design to determine that it contains all necessary informal 
explanatory text. 

If the entire high-level design is infomial, this work unit is not applicable and is therefore considered to be 
satisfied. 

Supporting narrative descriptions are necessary for those portions of the high-level design that are difficult to 
understand only from the semiformal or formal description (for example, to make clear the meaning of any 
formal notation). 

12.6.3.3.2 Work unit 3:ADV_HLD.2-2 

ISO/IEC 15408-3 ADV_HLD.2.2C: The high-level design shall be internally consistent. 

The evaluator shall examine the presentation of the high-level design to determine that it is internally 
consistent. 

For guidance on consistency analysis see A.3, Consistency analysis. 

The evaluator validates the subsystem interface specifications by ensuring that the interface specifications are 
consistent with the description of the purpose of the subsystem. 

12.6.3.3.3 Work unit 3:ADV_HLD.2-3 

ISO/IEC 15408-3 ADV_HLD.2.3C: The high-level design shall describe the structure of the TSF in tenvs of 
subsystems. 

The evaluator shall examine the high-level design to determine that the TSF is described in terms of 
subsystems. 



134 



1815671:2006 
ISO/IEC 18045 : 2005 

With respect to the high-level design, the term subsystem refers to large, related units (such as memory- 
management, file-management, process-management). Breaking a design into the basic functional areas aids 
in the understanding of the design. 

The primary purpose for examining the high-level design is to aid the evaluator's understanding of the TOE. 
The developer's choice of subsystem definition, and of the grouping of TSFs within each subsystem, are an 
important aspect of making the high-level design useful in understanding the TOE's intended operation. As 
part of this work unit, the evaluator should make an assessment as to the appropriateness of the number of 
subsystems presented by the developer, and also of the choice of grouping of functions within subsystems. 
The evaluator should ensure that the decomposition of the TSF into subsystems is sufficient for the evaluator 
to gain a high-level understanding of how the functionality of the TSF is provided. 

The subsystems used to describe the high-level design need not be called "subsystems", but should represent 
a similar level of decomposition. For example, the design may be decomposed using "layers" or "managers". 

There may be some interaction between the choice of subsystem definition and the scope of the evaluator's 
analysis. A discussion on this interaction is found following work unit ADV_HLD.2-10. 

1 2.6.3.3.4 Work unit 3:ADV_HLD.2-4 

ISO/IEC 15408-3 ADV_HLD.2.4C: The high-level design shall descnbe the security functionality provided by 
each subsystem of the TSF. 

The evaluator shall examine the high-level design to determine that it describes the security functionality of 
each subsystem. 

The security functional behaviour of a subsystem is a description of what the subsystem does. This should 
include a description of any actions that the subsystem may be directed to perform through its functions and 
the effects the subsystem may have on the security state of the TOE (e.g. changes in subjects, objects, 
security databases). 

12.6.3.3.5 Work unit 3:ADV_HLD.2-5 

ISO/IEC 15408-3 ADV_HLD.2.5C: The high-level design shall identify any underlying hardware, firmware, 
and/or software required by the TSF with a presentation of the functions provided by the supporting protection 
mechanisms implemented in that hardware, firmware, or software. 

The evaluator shall check the high-level design to determine that it identifies all hardware, firmware, and 
software required by the TSF. 

If the ST contains no security requirements for the IT environment, this work unit is not applicable and is 
therefore considered to be satisfied. 

If the ST contains the optional statement of security requirements for the IT environment, the evaluator 
compares the list of hardware, firmware, or software required by the TSF as stated in the high-level design to 
the statement of security requirements for the IT environment to determine that they agree. The information in 
the ST characterises the underlying abstract machine on which the TOE will execute. 

If the high-level design includes security requirements for the IT environment that are not included in the ST, 
or if they differ from those included in the ST, this inconsistency is assessed by the evaluator under Action 
ADV_HLD.2.2E. 

12.6.3.3.6 Work unit 3:ADV_HLD.2-6 

The evaluator shall examine the high-level design to determine that it includes a presentation of the functions 
provided by the supporting protection mechanisms implemented in the underlying hardware, firmware, or 
software. 
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If the ST contains no security Tequirements for the IT environment, this work unit is not applicable and Is 
therefore considered to be satisfied. 

The presentation of the functions provided by the underlying abstract machine on which the TOE executes 
need not be at the same level of detail as the presentation of functions that are part of the TSF. The 
presentation should explain how the TOE uses the functions provided in the hardware, firmware, or software 
that implement the security requirements for the IT environment that the TOE is dependent upon to support 
the TOE security objectives. 

The statement of security requirements for the IT. environment may be abstract, particularly if it is intended to 
be capable of being satisfied by a variety of different combinations of hardware, firmware, or software. As part 
of the Tests activity, where the evaluator is provided with at least one instance of an underlying machine that 
is claimed to satisfy the security requirements for the IT environment, the evaluator can determine whether it 
provides the necessary security functions for the TOE. This determination by the evaluator does not require 
testing or analysis of the underlying machine; it is only a determination that the functions expected to be 
provided by it actually exist. 

1 2.6.3.3.7 Work unit 3:ADV_HLD.2-7 

ISO/lEC 15408-3 ADV_HLD.2.6C: The high-level design shall identify all interfaces to the subsystems of the 
TSF. 

The evaluator shall check that the high-level design identffies the interfaces to the TSF subsystems. 

The high-level design includes, for each subsystem, the name of each of its entry points. 

12.6.3.3.8 Work unit 3:ADV_HLD.2-8 

ISO/lEC 15408-3 ADV_HLD.2.7C; The high-level design shall identify which of the interfaces to the 
subsystems of the TSF are externally visible. 

The evaluator shall check that the high-level design identifies which of the interfaces to the subsystems of the 
TSF are externally visible. 

As discussed under work unit ADV_FSP.1-3, external interfaces (i.e. those visible to the user) may directly or 
indirectly access the TSF. Any external interface that accesses the TSF either directly or indirectly is included 
in the identification for this work unit. External interfaces that do not access the TSF need not be included. 

12.6.3.3.9 Work unit 3:ADV,HLD.2-9 

ISO/lEC 15408-3 ADV_HLD.2.8C: The high-level design shall describe the purpose and method of use of all 
interfaces to the subsystems of the TSF, providing details of effects, exceptions and envr messages, as 
appropriate. 

The evaluator shall examine the high-level design to determine that it describes the interfaces to each 
subsystem in terms of their purpose and method of use, and provides details of effects, exceptions and enror 
messages, as appropriate. 

The high-level design should include descriptions in terms of the purpose and method of use for alt interfaces 
of each subsystem. Such descriptions may be provided in general terms for some interfaces, and in more 
detail for others. In determining the level of detail of effects, exceptions and error messages that should be 
provided, the evaluator should consider the purposes of this analysis and the uses made of the interface by 
the TOE. For example, the evaluator needs to understand the nature of the interactions between subsystems 
to establish confidence that the TOE design is sound, and may be able to obtain this understanding with only 
a general description of some of the interfaces between subsystems. In particular, internal subsystem entry 
points that ^re not called by any other subsystem would not normally require detailed descriptions. 
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The level of detail may also depend on the testing approach adopted to meet the Depth (ATE_DPT) 
requirement. For example, a different amount of detail may be needed for a testing approach that tests only 
through external interfaces than one that tests through both external and internal subsystem interfaces. 

Detailed descriptions would include details of any input and output parameters, of the effects of the Interface, 
and of any exceptions or error messages it produces. In the case of external interfaces, the required 
description is probably included in the functional specification and can be referenced in the high-level design 
without replication. 

12.6.3.3.10 Work unit 3:ADV_HLD.2-10 

ISO/IEC 15408-3 ADV_HLD.2.9C: The high-level design shall describe the separation of the TOE into TSP- 
enforcing and other sut>systems. 

The evaluator shall check that the high-level design describes the separation of the TOE into tSP-enforcing 
and other subsystems. 

The TSF comprises all the parts of the TOE that have to be relied upon for enforcement of the TSP. Because 
the TSF includes both functions that directly enforce the TSP. and also those functions that, while not directly 
enforcing the TSP, contribute to the enforcement of the TSP in a more indirect manner, all TSP-enforcing 
subsystems are contained in the TSF. Subsystems that play no role in TSP enforcement are not part of the 
TSF. An entire subsystem is part of the TSF if any portion of it is. 

As explained under work unit ADV_HLD.2-3, the developer's choice of subsystem definition, and of the 
grouping of TSFs within each subsystem, are important aspects of making the high-level design useful in 
understanding the TOE's intended operation. However, the choice of grouping of TSFs within subsystems 
also affects the scope of the TSF, because a subsystem with any function that directly or indirectly enforces 
the TSP is part of the TSF. While the goal of understandability is important, it is also helpful to limit the extent 
of the TSF so as to reduce the amount of analysis that is required. The two goals of understandability and 
scope reduction may sometimes work against each other. The evaluator should bear this in mind when 
assessing the choice of subsystem definition. 

12.6.3.4 Action ADV_HLD.2.2E 

12.6.3.4.1 Work unit 3:ADV_HLD.2-11 

The evaluator shall examine the high-level design to determine that it is an accurate instantiation of the TOE 
security functional requirements. 

The evaluator analyses the high-level design for each TOE security function to ensure that the function is 
accurately described. The evaluator also ensures that the function has no dependencies that are not included 
in the high-level design. 

The evaluator also analyses the security requirements for the IT environment in both the ST and the high-level 
design to ensure that they agree. For example, if the ST includes TOE security functional requirements for the 
storage of an audit trail, and the high-level design stated that audit trail storage is provided by the IT 
environment, then the high-level design is not an accurate instantiation of the TOE security functional 
requirements. 

The evaluator should validate the subsystem interface specifications by ensuring that the interface 
specifications are consistent with the description of the purpose of the subsystem. 

12.6.3.4.2 Workumt3:ADV_HLD.2-12 

The evaluator shall examine the high-level design to determine that it is a complete instantiation of the TOE 
security functional requirements. 

To ensure that all ST security functional requirements are covered by the high-level design, the evaluator may 
construct a map between the TOE security functional requirements and the high-level design. 
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12.6.4 Evaluation of Representation correspondence (ADV_RCR.1) 

12.6.4.1 Objectives 

The objective of this sub-activity is to determine whether the developer has correctly and completely 
implemented the requirements of the ST and functional specification in the high-level design. 

12.6.4.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the correspondence analysis between the TOE summary specification and the functional specification; 

e) the correspondence analysis between the functional specification and the high-level design; 

12.6.4.3 Action ADV_RCR.1. IE 

1 2.6.4.3.1 Work unit 3:ADV_RCR.1 -1 

ISO/lEC 15408-3 ADV_RCR.1.1C: For each adjacent pair of provided TSF representations, the analysis shall 
demonstrate Ihat all relevant security functionality of the more abstract TSF representation is correctly and 
completely refined in the less abstract TSF representation. 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaiuator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

12.6.4.3.2 Workunit3:ADV_RCR.1-2 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
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verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

12.6.4.3.3 Workunit3:ADV_RCR.1-3 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representatron 
of the TOE-security functions. 

The ©valuator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

12.6.4.3.4 Work unit 3:ADV_RCR.1-4 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, tlie evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.2-8 and ADV_FSP.2-9. 

12.6.4.3.5 Work unit 3:ADV_RCR.1-5 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

1 2.6.4.3.6 Work unit 3:ADV_RCR.1 -6 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to detemitne that the high-level design is a correct and complete representation of the functional 
specification. 
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The evaluator uses the correspondence analysis, the functional specification, and the high-level design 1o 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

1 2.6.4.3.7 Work unit 3:ADV_RCR.1 -7 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

12.6.4.3.8 Work unit 3:ADV_RCR.1-8 

The evaluator shall examine the correspondence analysis between the high-level design and the low-level 
design to determine that the low-level design is a correct and complete representation of the high-level design. 

The evaluator uses the correspondence analysis, the high-level design, and the iow-levet design to ensure 
that it is possible to map each TSF module identified in the low-level design onto a TSF subsystem described 
in the high-level design. For each TOE security function, the correspondence indicates which TSF modules 
are involved in the support of the function. The evaluator verifies that the low-level design includes a 
description of a correct realisation of each security function. 

12.6.4.3.9 Work unit 3:ADV_RCR.1.9 

The evaluator shall examine the correspondence analysis between the low-level design and the subset of the 
implementation representation to determine that the subset is a correct and complete representation of those 
portions of the low-level design that are refined in the implementation representation. 

Since the evaluator examines only a subset of the implementation representation, this work unit is perfomied 
by assessing the correspondence analysis of the subset of the implementation representation to the relevant 
parts of the low-level design rather than attempting to trace each TOE security function into the 
implementation representation. The subset may provide no coverage for some functions. 

12.7 Guidance documents activity 

The purpose of the guidance document activity is to judge the adequacy of the documentation describing how 
to use the operational TOE. Such documentation includes both that aimed at trusted administrators and non- 
administrator users whose incorrect actions could adversely affect the security of the TOE, as well as that 
aimed at untrusted users whose incon-ect actions could adversely affect the security of their own data. 

12.7.1 Application notes 

The guidance documents activity applies to those functions and interfaces which are related to the security of 
the TOE. The secure configuration of the TOE is described in the ST. 

12.7.2 Evaluation of Administrator guidance (AGD_ADM.1) 
12.7.2.1 Objectives 

The objective of this sub-activity is to determine whether the administrator guidance describes how to 
administer the TOE in a secure manner. 
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12.7.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the life-cycle definition. 

12.7.2.3 Application notes 

The term "administrator" is used to indicate a human user who Is trusted to perform security critical operations 
within the TOE, such as setting TOE configuration parameters, The operations may affect the enforcement of 
\he TSP, and the administrator therefore possesses specific privileges necessary to perfonn those operations. 
The role of the administrator(s) has to be clearly distinguished from the role of non-administrative users of the 
TOE. 

There may be different administrator roles or groups defined in the ST that are recognised by the TOE and 
that can interact with the TSF such as auditor, administrator, or daily-management. Each role can encompass 
an extensive set of capabilities, or can be a single one. The capabilities of these roles and their associated 
privileges are described in the FMT class. Different administrator roles and groups should be taken into 
consideration by the administrator guidance. 

12.7.2.4 Action AGD_ADM.1. IE 

12.7.2.4.1 Work unit 3:AGD_ADM.1-1 

ISO/IEC 15408-3 AGD_ADM.1.1C: The administrator guidance sf^all describe the administrative functions and 
interfaces available to the administrator of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes the administrative 
security functions and interfaces available to the administrator of the TOE. 

The administrator guidance should contain an overview of the security functionality that is visible at the 
administrator interfaces. 

The administrator guidance should identify and describe the purpose, behaviour, and interrelationships of the 
administrator security interfaces and functions. 

For each administrator security interface and function, the administrator guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system calls, menu selection, command button); 

b) describe the parameters to be set by the administrator, their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 
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12.7.2.4.2 Workunit3:AGD_ADM.1-2 

ISO/IEC 1 5408-3 AGD_ADM.1 .2C: The administrator guidance sliall describe how to administer the TOE in a 
secure manner 

The evaluator shall examine the administrator guidance to determine that it describes how to administer the 
TOE in a secure manner. 

The administrator guidance describes how to operate the TOE according to the TSP in an IT environment that 
is consistent with the one described in the ST. 

12 J.2.4.3 Work unit 3:AGD_ADM.1-3 

ISO/IEC 15408-3 AGD_ADM.1.3C: The administrator guidance shall contain warnings about functions and 
privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the administrator guidance to determine that it contains warnings about functions 
and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges to make use of the different 
functions of the TOE. This means that some users may be authorised to perform certain functions while other 
users may not be so authorised. These functions and privileges should be described by the administrator 
guidance. 

The administrator guidance identifies the functions and privileges that must be controlled, the types of controls 
required for them, and the reasons for such controls. Warnings address expected effects, possible side effects, 
and possible interactions with other functions and privileges. 

12.7.2.4.4 Work unit 3:AGD_ADM.1-4 

ISO/IEC 15408-3 AGD_ADM.1.4C: The administrator guidance shall describe all assumptions regarding user 
behaviour that are relevant to secure operation of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes all assumptions 
regarding user behaviour that are relevant to the secure operation of the TOE. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the administrator guidance. 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

12.7.2.4.5 Workunit3:AGD_ADIVI.1-S 

ISO/IEC 15408-3 AGD_ADM.1.5C: The administrator guidance shall describe all security parameters under 
the control of the administrator, indicating secure values as appropriate. 

The evaluator shall examine the administrator guidance to determine that it describes all security parameters 
under the control of the administrator indicating secure values as appropriate. 

For each security parameter, the administrator guidance should describe the purpose of the parameter, the 
valid and default values of the parameter, and secure and insecure use settings of such parameters, both 
individually or in combination. 



142 



IS 15671 : 2006 
ISO/IEC 18045:2005 



UJ.IA.B Workunrt3:AGD ADM.1-6 



ISO/IEC 15408-3 AGD_ADM.1.6C: The administrator guidance shall describe each type of security-relevant 
event relative to the administrative functions that need to be performed, including changing the security 
characteristics of entities under the control of the TSF. 

The evaluator shall examine the administrator guidance to determine that it describes each type of security- 
relevant event relative to the administrative functions that need to be performed, including changing the 
security characteristics of entities under the control of the TSF. 

All types of security-relevant events are detailed, such that an administrator knows what events may occur 
and what action (if any) the administrator may have to take in order to maintain security. Security-relevant 
events that may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user 
records, such as when a user account is removed when the user leaves the organisation) are adequately 
defined to allow administrator intervention to maintain secure operation. 

12.7.2.4.7 Work unit 3:AGD_ADM.1-7 

ISO/IEC 15408-3 AGD_ADM.1.7C: The administrator guidance shall be consistent with all other 
documentation supplied for evaluation. 

The evaluator shall examine the administrator guidance to determine that it is consistent with all other 
documents supplied for evaluation. 

The ST in particular may contain detailed information on any wamings to the TOE administrators with regard 
to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 

12.7.2.4.8 Work unit 3:AGD_ADIVI.1-8 

ISO/IEC 15408-3 AGD_ADM.1.8C: The administrator guidance shall describe all secuhty requirements for the 
IT environment that are relevant to the administrator 

The evaluator shall examine the administrator guidance to determine that it describes all IT security 
requirements for the IT environment of the TOE that are relevant to the administrator. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

t 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare them with the administrator guidance to ensure that all security requirements of the 
ST that are relevant to the administrator are described appropriately in the administrator guidance. 

12.7.3 Evaluation of User guidance (AGD_USR.1) 

12.7.3.1 Obiectives 

The objectives of this sub-activity are to determine whether the user guidance describes the security functions 
and interfaces provided by the TSF and whether this guidance provides instructions and guidelines for the 
secure use of the TOE. 

12.7.3.2 Input 

The evaluation evidence for this sub-activity is: 
a) the ST; 
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b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures. 

12.7.3.3 Application notes 

There may be different user roles or groups defined in the ST that are recognised by the TOE and that can 
interact with the TSF. The capabilities of these roles and their associated privileges are described in the FMT 
class. Different user roles and groups should be taken into consideration by the user guidance. 

1 2.7.3.4 Action AGD_USR.1 .1 E 

12.7.3.4.1 Work unit3:AGD_USR.1-1 

ISO/IEC 15408-3 AGD_USR.1.1C: The user guidance shall describe the functions and interfaces available to 
the non-administrative users of the TOE. 

The evaluator shall examine the user guidance to determine that it describes the security functions and 
interfaces available to the non-administrative users of the TOE. 

The user guidance should contain an overview of the security functionality that is visible at the user interfaces. 

The user guidance should identify and describe the purpose of the security interfaces and functions. 

12.7.3.4.2 Work unit 3:AGD_USR.1-2 

ISO/IEC 15408-3 AGD_USR.1.2C: The user guidance shall describe the use of user-accessible security 
functions provided by the TOE. 

The evaluator shall examine the user guidance to determine that it describes the use of user-accessible 
security functions provided by the TOE. 

The user guidance should identify and describe the behaviour and interrelationship of the security interfaces 
and functions available to the user. 

If the user is allowed to Invoke a TOE security function, the user guidance provides a description of the 
interfaces available to the user for that function. 

For each interface and function, the user guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system call, menu selection, command button) ; 

b) describe the parameters to be set by the user and their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

12.7.3.4.3 Workunit3:AGD_USR.1-3 

tSO/lEC 15408-3 AGD_USR.1.3C: The user guidance shall contain warnings about user-accessible functions 
and privileges that should be controlled in a secure processing environment. 
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The evaluator shall examine the user guidance to determine that it contains warnings about user-accessible 
functions and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges in making use of the different 
functions of the TOE. This means that some users are authorised to perform certain functions, while other 
users may not be so authorised. These user-accessible functions and privileges are described by the user 
guidance. 

The user guidance should identify the functions and privileges that can be used, the types of commands 
required for them, and the reasons for such commands. The user guidance should contain warnings regarding 
the use of the functions and privileges that must be controlled. Warnings should address expected effects, 
possible side effects, and possible interactions with other functions and privileges. 

12.7.3.4.4 Workunit3:AGD_USR.1-4 

ISO/tEC 15408-3 AGD_USR.1.4C: The user guidance shall clearly present all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

The evaluator shall examine the user guidance to determine that it presents all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the user guidance. 

The user guidance should provide advice regarding effective use of the security functions (e.g. reviewing 
password composition practices, suggested frequency of user file backups, discussion on the effects of 
changing user access privileges). 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

The user guidance should indicate whether the user can invoke a function or whether the user requires the 
assistance of an administrator. 

12.7.3.4.6 Workunit3:AGD_USR.1-5 

ISO/IEC 15408-3 AGD_USR.1.5C: The user guidance shall be consistent v\fith all other documentation 
supplied for evaluation. 

The evaluator shall examine the user guidance to determine that it is consistent with all other documentation 
supplied for evaluation. 

The evaluator ensures that the user guidance and all other documents supplied for evaluation do not 
contradict each other. This is especially true if the ST contains detailed information on any warnings to the 
TOE users with regard to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A.3, Consistency analysis. 

1 2.7.3.4.6 Work unit 3:AGD_USR.1 -6 

ISO/IEC 15408-3 AGD_USR.1.6C: The user guidance shall describe all security requirements for the IT 
environment that are relevant to the user. 

The evaluator shall examine the user guidance to determine that it describes all security requirements for the 
IT environment of the TOE that are relevant to the user. 
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If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare that with the user guidance to ensure that all security requirements of the ST, that are 
relevant to the user, are described appropriately in the user guidance. 

12.8 Life cycle support activity 

The purpose of the life-cycle support activity is to determine the adequacy of the security procedures the 
developer uses during the development and maintenance of the TOE. Such procedures are intended to 
protect the TOE and its associated design information from interference or disclosure. Interference in the 
developement process may allow the deliberate introduction of vulnerabilities. Disclosure of design 
information may allow vulnerabilities to be more easily exploited. The adequacy of the procedures will depend 
on the nature of the TOE and the development process. 

12.8.1 Evaluation of Development security (ALC_DVS.1) 

12.8.1.1 Objectives 

The objective of this sub-activity is to determine whether the developer's security controls on the development 
environment are adequate to provide the confidentiality and integrity of the TOE design and implementation 
that is necessary to ensure that secure operation of the TOE is not compromised. 

12.8.1.2 Input 

The evaluation evidence for this sub-activity Is: 

a) the ST; 

b) the development security documentation. 

In addition, the evaluator may need to examine other deliverables to determine that the security controls are 
well-defined and followed. Specifically, the evaluator may need to examine the developer's configuration 
management documentation (the input for the ACM_CAP.4 Generation support and acceptance procedures 
and ACM_SCP.2 Problem tracking CM coverage sub-activities). Evidence that the procedures are being 
applied is also required. 

1 2.8.1 .3 Action ALC_DVS.1 .1 E 

12.8.1.3.1 Work unit 3:ALC_DVS.1-1 

ISO/IEC 15408-3 ALC_DVS.1.1C: The development security documentation shall descritte all the physical, 
procedural, personnel, and other security measures that are necessary to protect the confidentiality and 
integrity of the TOE design and implementation in its development environment. 

The evaluator shall examine the development security documentation to determine that it details alt security 
measures used in the development environment that are necessary to protect the confidentiality and Integrity 
of the TOE design and implementation. 

The evaluator d,etermines what is necessary by first referring to the ST for any information that may assist in 
the determinatiJDn of necessary protection, especially the subclauses on threats, organisational security 
policies and assumptions, although there may be no information provided explicitly. The statement of security 
objectives for the environment may also be useful in this respect. 

If no explicit information is available from the ST the evaluator will need to make a determination of the 
necessary measures, based upon a consideration of the intended environment for the TOE. In cases where 
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the developer's measures are considered less than what is necessary, a clear justification should be provided 
for the assessment, based on a potential exploitable vulnerability. 

The following types of security measures are considered by the evaluator when examining the documentation: 

a) physical, for example physical access controls used to prevent unauthorised access to the TOE 
development environment (during normal working hours and at other times); 

b) procedural, for example covering: 

granting of access to the development environment or to specific parts of the environment such as 
development machines 

revocation of access rights when a person leaves the development team 

transfer of protected material out of the development environment 

admitting and escorting visitors to the development environment 

roles and responsibilities in ensuring the continued application of security measures, and the detection 
of security breaches. 

c) personnel, lor example any controls or checks made to establish the trustworthiness of new development 
staff; 

d) other security measures, for example the logical protections on any development machines. 

The development security documentation should identify the locations at which development occurs, and 
describe the aspects of development performed, along with the security measures applied at each location. 
For example, development could occur at multiple facilities within a single building, multiple buildings at the 
same site, or at multiple sites. Development includes such tasks as creating multiple copies of the TOE, where 
applicable. This work-unit should not overlap with those for Delivery (ADO_DEL), but the evaluator should 
ensure that all aspects are covered by one sub-activity or the other. 

In addition, the development security documentation may describe different security measures that can be 
applied to different aspects of development in terms of their performance and the required inputs and outputs. 
For example, different procedures may be applicable to the development of different portions of the TOE, or to 
different stages of the development process. 

12.8.1.3.2 Wofkunit3:ALC_DVS.1-2 

The evaluator shall examine the development confidentiality and integrity policies in order to determine the 
sufficiency of the security measures employed. 

These include the policies governing: 

a) what information relating to the TOE development needs to be kept confidential, and which members of 
the development staff are allowed to access such material; 

b) what material must be protected from unauthorised modification in order to preserve the integrity of the 
TOE, and which members of the development staff are allowed to modify such material. 

The evaluator should determine that these policies are described in the development security documentation, 
that the security measures employed are consistent with Ihe policies, and that they are complete. 

It should be noted that configuration management procedures will help protect the integrity of the TOE and the 
evaluator should avoid overlap with the work-units conducted for the CM capabilities {ACM_CAP) sub-activity. 
For example, the CM documentation may describe the security procedures necessary for controlling the roles 
or individuals who should have access to the development environment and who may modify the TOE. 
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Whereas the CM capabilities (ACM_CAP) requirements are fixed, those for Development security (ALC_DVS), 
mandating only necessary measures, are dependent on the nature of the TOE, and on information that may 
be provided in the Security Environment subclause of the ST. For example, the ST may identify an 
organisational security policy that requires the TOE to be developed by staff who have security clearance. The 
evaluators would then determine that such a policy had been applied under this sub-activity. 

12.8.1.3.3 Workunlt3:ALC_DVS.1-3 

ISO/IEC 15408-3 ALC_DVS.1.2C: The development security documentation shall provide evidence that these 
security measures are followed during the development and maintenance of the TOE. 

The evaluator shall check the development security documentation to determine that documentary evidence 
that would be produced as a result of application of the procedures has been generated. 

Where documentary evidence is produced the evaluator inspects it to ensure compliance with procedures. 
Examples of the evidence produced may include entry logs and audit trails. The evaluator may choose to 
sample the evidence. 

For guidance on sampling see A.2, Sampling. 

12.8.1.4 Action ALC_DVS.1.2E 

12.8.1.4.1 Work unit 3:ALC_DVS.1-4 

The evaluator shall examine the development security documentation and associated evidence to determine 
that the security measures are being applied. 

This work unit requires the evaluator to determine that the security measures described in the development 
security documentation are being followed, such that the integrity of the TOE and the confidentiality of 
associated documentation is being adequately protected. For example, this could be determined by 
examination of the documentary evidence provided. Documentary evidence should be supplemented by 
visiting the development environment. A visit to the development environment will allow the evaluator to: 

a) observe the application of security measures (e.g. physical measures); 

b) examine documentary evidence of application of procedures; 

c) interview development staff to check awareness of the development security policies and procedures, 
and their responsibilities. 

A development site visit is a useful means of gaining confidence in the measures being used. Any decision not 
to make such a visit should be determined in consultation with the overseer. 

For guidance on site visits see A.5, Site Visits. 

12.9 Tests activity 

The purpose of this activity is to determine whether TSF behaves as specified in the design documentation 
and in accordance with the TOE security functional requirements specified in the ST. This is accomplished by 
determining that the developer has tested the TSF against its functional specification and high-level design, 
gaining confidence in those test results by performing a sample of the developer's tests, and by independently 
testing a subset of the TSF. 

12.9.1 Application notes 

The size and composition of the evaluator's test subset depends upon several factors discussed in the 
independent testing (ATE_IND.2 Independent testing - sample) sub-activity. One such factor affecting the 
composition of the subset is Known public domain weaknesses, information about which the evaluator needs 
access (e.g. from a scheme). 
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ISO/IEC 15408 has separated coverage and depth from functional tests to increase the flexibility when 
applying the components of the families. However, the requirements of the families are intended to be applied 
together to confirm that the TSF operates according to its specification. This tight coupling of families has led 
to some duplication of evaluator work effort across sub-activities. These application notes are used to 
minimize duplication of text between sub-activities of the same activity and EAL. 

12.9.1.1 Understanding the expected behaviour of the TOE 

Before the adequacy of test documentation can be accurately evaluated, or before new tests can be created, 
the evaluator has to understand the desired expected behaviour of a security function in the context of the 
requirements it is to satisfy. 

The evaluator may choose to focus on one security function of the TSF at a time. For each security function, 
the evaluator examines the ST requirement and the relevant parts of the functional specification, high-level 
design and guidance documentation to gain an understanding of the way the TOE is expected to behave. 

With an understanding of the expected behaviour, the evaluator examines the test plan to gain an 
understanding of the testing approach. In most cases, the testing approach will entail a security function being 
stimulated at either the external or internal interfaces and its responses are observed. However, there may be 
cases where a security function cannot be adequately tested at an interface (as may be the case, for instance, 
for residual information protection functionality); in such cases, other means wilt need to be employed. 

12.9.1.2 Testing vs. alternate approaches to verify the expected behaviour of a security function 

In cases where it is impractical or inadequate to test at an interface, the test plan should identify the alternate 
approach to verify expected behaviour. It is the evaluator's responsibility to determine the suitability of the 
alternate approach. However, the following should be considered when assessing the suitability of alternate 
approaches: 

a) an analysis of the implementation representation to determine that the required behaviour should be 
exhibited by the TOE is an acceptable alternate approach. This could mean a code inspection for a 
software TOE or perhaps a chip mask inspection for a hardware TOE. 

b) it is acceptable to use evidence of developer integration or module testing, even if the EAL is not 
commensurate with evaluation exposure to the low-level design or implementation. If evidence of 
developer integration or module testing is used in verifying the expected behaviour of a security function, 
care should be given to confirm that the testing evidence reflects the current implementation of the TOE. 
If the subsystem or modules have been changed since testing occurred, evidence that the changes were 
tracked and addressed by analysis or further testing will usually be required. 

It should be emphasized that supplementing the testing effort with alternate approaches should only be 
undertaken when both the developer and evaluator determine that there exists no other practical means to 
test the expected behaviour of a security function. This alternative is made available to the developer to 
minimize the cost (time and/or money) of testing under the circumstances described above; it is not designed 
to give the evaluator more latitude to demand unwarranted additional information about the TOE, nor to 
replace testing in general. 

12.9.1.3 Verifying the adequacy of tests 

Test pre-requisites are necessary to establish the required initial conditions for the test. They may be 
expressed in terms of parameters that must be set or in terms of test ordering in cases where the completion 
of one test establishes the necessary pre-requisites for another test. The evaluator must determine that the 
pre-requisites are complete and appropriate in that they will not bias the observed test results towards the 
expected test results. 

The test steps and expected results specify the actions and parameters to be applied to the interfaces as well 
as how the expected results should be verified and what they are. The evaluator must deteirmine that the test 
steps and expected results are consistent with the functional specification and the high-level design. The tests 
must verify behaviour documented in these specifications. This means that each security functional behaviour 
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characteristic explicitly described in the functional specification and high-level design should have tests and 
expected results to verify that behaviour. 

Although all of the TSF has to be tested by the developer, exhaustive specification testing of the interfaces is 
not required. The overall aim of this activity is to determine that each security function has been sufficiently 
tested against the behavioural claims in the functional specification and high-level design. The test procedures 
will provide insight as to how the security functions have been exercised by the developer during testing. The 
evaluator will use this information when developing additional tests to independently test the TOE. 

12.9.2 Evaluation of Coverage (ATE_C0V.2) 

12.9.2.1 Objectives 

The objective of this sub-activity is to determine whether the testing (as docuntented) is sufficient to establish 
that the TSF has been systematically tested against the functional specification. 

12.9.2.2 Input 

a) the ST; 

b) the functional specification; 

c) the test documentation; 

d) the test coverage analysis. 

1 2.9.2.3 Action ATE_C0V.2.1 E 

12.9.2.3.1 Work unit 3:ATE_COV.2-1 

ISO/IEC 15408-3 ATE_C0V.2.1C: The analysis of the test coverage shall demonstrate the correspondence 
between the tests identified in the test documentation and the TSF as described in the functional specification. 

The evaluator shall examine the test coverage analysis to determine that the correspondence between the 
tests identified in the test documentation and the functional specification is accurate. 

Correspondence may take the form of a table or matrix, tn some cases mapping may be sufficient to show test 
correspondence. In other cases a rationale (typically prose) may have to supplement the correspondence 
analysis provided by the developer. 

Figure 10 displays a conceptual framework of the correspondence between security functions described in the 
functional specification and the tests outlined in the test documentation used to test them. Tests may involve 
one or multiple security functions depending on the test dependencies or the overall goal of the test being 
performed. 

The identification of the tests and the security functions presented in the test coverage analysis has to be 
unambiguous. The test coverage analysis will allow the evaluator to trace the identified tests back to the test 
documentation and the particular security function being tested back to the functional specification. 

12.9.2.3.2 Work unit 3:ATE_COV.2-2 

The evaluator shall examine the test plan to determine that the testing approach for each security function of 
the TSF is suitable to demonstrate the expected behaviour. 

Guidance on this work unit can be found in: 

a) Understanding the expected behaviour of the TOE 

b) Testing vs. alternate approaches to verify the expected behaviour of a security function 
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12.9.2.3.3 Work unit 3:ATE_COV.2-3 



The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and 
expected result(s) adequately test each security function. 

Guidance on this work units, as it pertains to the functional specification, can be found in: 

a) Verifying the adequacy of tests 

1 2.9.2.3.4 Work unit 3: ATE_COV.2-4 

ISO/IEC 15408-3 ATE_COV.2.2C: The analysis of the test coverage shall demonstrate that the 
correspondence between the TSF as described in the functional specification and the tests identified in the 
test documentation is complete. 

The evaluator shall examine the test coverage analysis to determine that the correspondence between the 
TSF as described in the functional specification and the tests Identified in the test documentation is complete. 

All security functions and interfaces that are described in the functional specification have to be present in the 
test coverage analysis and mapped to tests in order for completeness to be claimed, although exhaustive 
specification testing of interfaces is not required. As Figure 10 displays, all the security functions have tests 
attributed to them and therefore complete test coverage is depicted in this example. Incomplete coverage 
would be evident if a security function was identified in the test coverage analysis and no tests could be 
attributed to it. 
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Figure 10 - A conceptual framework of the test coverage analysis 

12.9.3 Evaluation of Depth (ATE_DPT.1) 

12.9.3.1 Objectives 

The objective of thjs sub-activity is to determine whether the developer has tested the TSF against its high- 
level design. 

12.9.3.2 Input 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the test documentation; 

e) the depth of testing analysis. 
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12.9.3.3 Action ATE_DPT.1. IE 

12.9.3.3.1 Work unit 3:ATE_DPT.1-1 

ISO/IEC 15408-3 ATE_DPT.1.1C: The depth analysis shall demonstrate that the tests identified in the test 
documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design. 

The evaluator shall examine the depth of testing analysis for a mapping between the tests identified in the test 
documentation and the high-level design. 

The depth of testing analysis identifies all subsystems described in the high-level design and provides a 
mapping of the tests to these subsystems. Correspondence may take the form of a table or matrix. In some 
cases the mapping may be sufficient to show test correspondence. In other cases a rationale (typically prose) 
may have to supplement the mapping evidence provided by the developer. 

All design details specified in the high-level design that map to and satisfy TOE security requirements are 
subject to testing and hence, should be mapped to test documentation. Figure 11 displays a conceptual 
framework of the mapping between subsystems described in the high-level design and the tests outlined in 
the TOE'S test documentation used to test them. Tests may involve one or multiple security functions 
depending on the test dependencies or the overall goal of the test being performed. 

12.9.3.3.2 Work unit 3:ATE_DPT.1-2 

The evaluator shall examine the developer's test plan to determine that the testing approach for each security 
function of the TSF is suitable to demonstrate the expected behaviour. 

Guidance on this work unit can be found in: 

a) Understanding the expected behaviour of the TOE 

b) Testing vs. alternate approaches to verify the expected behaviour of a security function 

Testing of the TSF may be performed at the external interfaces, internal interfaces, or a combination of both. 
Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the security 
functions. Specifically the evaluator determines whether testing at the internal interfaces for a security function 
is necessary or whether these internal interfaces can be adequately tested (albeit implicitly) by exercising the 
external interfaces. This determination is left to the evaluator, as is its justification. 

12.9.3.3.3 Work unit 3:ATE_DPT.1-3 

The evaluator shall examine the test procedures to determine that the test pre-requisites, test steps and 
expected result(s) adequately test each security function. 

Guidance on this work units, as it pertains to high level design, can be found in: 

a) Verifying the adequacy of tests 

12.9.3.3.4 Work unit 3:ATE_DPT.1-4 

The evaluator shall check the depth of testing analysis to ensure that the TSF as defined in the high-level 
design is completely mapped to the tests in the test documentation. 

The depth of testing analysis provides a complete statement of correspondence between the high-level design 
and the test plan and procedures. All subsystems and internal interfaces described in the high-level design 
have to be present in the depth of testing analysis. All the subsystems and internal interfaces present in the 
depth of testing analysis must have tests mapped to them in order for completeness to be claimed. As Figure 
1 1 displays, all the subsystems and internal interfaces have tests attributed to them and therefore complete 
depth of testing is depicted in this example. Incomplete coverage would be evident if a subsystem or internal 
interface was identified in the depth of testing analysis and no tests could be attributed to it. 
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Figure 11 -A conceptual framework of the depth of testing analysis 
12.9.4 Evaluation of Functional tests {ATE_FUN.1) 
12.9.4.1 Objectives 

The objective of this sub-activity is to determine whether the developer's functional test documentation is 
sufficient to demonstrate that security functions perform as specified. 
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12.9.4.2 Input 

The evaluation evidence for this sub-activity is; 

a) the ST; 

b) the functional specification; 

c) the test documentation; 

d) the test procedures. 

12.9.4.3 Application notes 

The extent to which the test documentation is required to cover the TSF is dependent upon the coverage 
assurance component. 

For the developer tests provided, the evaluator determines whether the tests are repeatable, and the extent to 
which the developer's tests can be used for the evaluator's independent testing effort. Any security function for 
which the developer's test results indicate that it may not perform as specified should be tested independently 
by the evaluator to determine whether or not it does. 

The test documentation will identify any instances where privileged modes are used to set up test 
conditions/cleanup for further tests. The test documentation will describe why it was necessary to use 
privileged modes to obtain the necessary conditions (e.g. efficiency of the test harness, to generate specific 
objects required for a test that unprivileged users are unable to create) and also how the privileged modes are 
exited prior to the conduct of the test steps demonstrating the security functionality of the TOE. Therefore, 
although the test configuration may be inconsistent with the TOE as described in the ST during the 
establishment of the test conditions the test documentation will describe how the configuration is returned to a 
state that is consistent with the configuration described in the ST for the conduct of the test steps. 

12.9.4.4 Action ATE_FUN.1.1E 

12.9.4.4.1 Work unit 3:ATE_FUN.1-1 

ISO/IEC 15408-3 ATE_FUN.1.1C: The test documentation shall consist of test plans, test procedure 
descriptions, expected test results and actual test results. 

The evaluator shall check that the test documentation includes test plans, test procedure descriptions, 
expected test results and actual test results. 

12.9.4.4.2 Workunit3:ATE_FUN.1-2 

ISO/IEC 15408-3 ATE_FUN.1 ,2C: The test plans shall identify the security functions to be tested and describe 
the goal of the tests to be performed. 

The evaluator shall check that the test plan identifies the security functions to be tested. 

One method that could be used to identify the security function to be tested is a reference to the appropriate 
part(s) of the functional specification that specifies the particular security function. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

12.9.4.4.3 Work unit 3:ATE_FUN.1-3 

The evaluator shall examine the test plan to determine that it describes the goal of the tests performed. 
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The test plan provides information about how the security functions are tested and the test configuration in 
which testing occurs. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

1 2.9.4.4.4 Work unit 3:ATE_FUN.1-4 

The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the 
configuration identified for evaluation in the ST. 

The TOE referred to in the developer's test plan should have the same unique reference as established by the 
CM capabilities (ACM_CAP).* sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation. The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator verifies that there are test configurations identified in the developer test documentation that ate 
consistent with each evaluated configuration described in the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

12.9.4.4.5 WorkunJt3:ATE_FUN.1-5 

The evaluator shall examine the test plan to determine that it is consistent with the test procedure descriptions. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A,3, Consistency 
analysis. 

12.9.4.4.6 Work unit 3:ATE_FUN.1-6 

ISO/IEC 15408-3 ATE_FUN.1 .3C: The test procedure descriptions shall identify the tests to be performed and 
describe the scenarios for testing each security function. These scenarios shall include any ordering 
dependencies on the results of other tests. 

The evaluator shall check that the test procedure descriptions identify each security function behaviour to be 
tested. 

One method that may be used to identify the security function behaviour to be tested is a reference to the 
appropriate part(s) of the design specification that specifies the particular behaviour to be tested. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

12.9.4.4.7 Work unit 3:ATE_FUN.1-7 

The evaluator shall examine the test procedure descriptions to determine that sufficient instructions are 
provided to establish reproducible initial test conditions including ordering dependencies if any. 

Some steps may have to be performed to establish initial conditions. For example, user accounts need to be 
added before they can be deleted. An example of ordering dependencies on the results of other tests Is the 
need to test the audit function before relying on it to produce audit records for another security mechanism 
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such as access control. Another example of an ordering dependency would be where one test case generates 
a file of data to be used as input for another test case. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A. 2, Sampling. 

12.9.4.4.8 Workunit3:ATE_FUN.1-8 

The evaluator shall examine the test procedure descriptions to determine that sufficient instructions are 
provided to have a reproducible means to stimulate the security functions and to observe their behaviour. 

Stimulus is usually provided to a security function externally through the TSFl. Once an input (stimulus) is 
provided to the TSFl, the behaviour of the security function can then be observed at the TSFl. Reproducibility 
is not assured unless the test procedures contain enough detail to unambiguously describe the stimulus and 
the behaviour expected as a result of this stimulus. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

12.9.4.4.9 Work unit 3:ATE_FUN.1-9 

The evaluator shall examine the test procedure descriptions to determine that they are consistent with the test 
procedures. 

If the test procedure descriptions are the test procedures, then this work unit is not applicable and is therefore 
considered to be satisfied. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A.3, Consistency 
analysis. 

12.9.4.4.10 Work unit 3:ATE_FUN.1-10 

ISO/IEC 15408-3 ATE_FUN.1.4C: The expected test results sttall st^ow the anticipated outputs from a 
successful execution of the tests. 

The evaluator shall examine the test documentation to determine that sufficient expected tests results are 
included. 

The expected test results are needed to determine whether or not a test has been successfully performed. 
Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the 
testing approach. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

12.9.4.4.11 Work unit 3:ATE_FUN.1-11 

ISO/IEC 15408-3 ATE_FUN.1 .5C: The test results from the developer execution of the tests shall demonstrate 
that each tested security function behaved as specified. 

The evaluator shall check that the expected test results in the test documentation are consistent with the 
actual test results provided. 
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A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies 
between the results. 

It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has 
been first performed. In such cases, the developer's test documentation should describe the process to 
reduce or synthesize the actual data. 

For example, the developer may need to test the contents of a message buffer after a network connection has 
occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary 
number would have to be converted to another form of data representation in order to make the test more 
meaningful. The conversion of this binary representation of data into a higher-level representation will have to 
be described by the developer in enough detail to allow an evaluator to perform the conversion process (i.e. 
synchronous or asynchronous transmission, number of stop bits, parity, etc). 

It should be noted that the description of the process used to reduce or synthesize the actual data is used by 
the evaluator not to actually perform the necessary modification but to assess whether this process is correct. 
It is up to the developer to transform the expected test results into a format that allows an easy comparison 
with the actual test results. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A. 2, Sampling. 

If the expected and actual test results for any test are not the same, then a demonstration of the correct 
operation of a security function has not been achieved. Such an occurrence will influence the evaluator's 
independent testing effort to include testing the implicated security function. The evaluator should also 
consider increasing the sample of evidence upon which this work unit is performed. 

12.9.4.4.12 Work unit 3:ATE_FUN.1-12 

The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and 
results. 

The developer testing information recorded in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing of the TOE by the developer. The intent of providing this 
information is to give a meaningful overview of the developer testing effort. It is not intended that the 
information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of 
individual tests. The intention is to provide enough detail to allow other evaluators and overseers to gain some 
insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the 
overall results of the developer testing. 

Information that would typically be found in the ETR subclause regarding the developer testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested; 

b) testing approach. An account of the overall developer testing strategy employed; 

c) amount of developer testing performed. A description on the extent of coverage and depth of developer 

testing; 

d) testing results. A description of the overall developer testing results. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the developer testing effort. 
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12.9.5 Evaluation of Independent testing (ATEJND.2) 

12.9.5.1 Objectives 

The goal of this activity is to determine, by Independently testing a subset of the TSF. whether the TOE 
behaves as specified, and to gain confidence in the developer's test results by performing a sample of the 
developer's tests. 

12.9.5.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance; 

e) the secure installation, generation, and start-up procedures; 

f) the test documentation; 

g) the test coverage analysis; 
h) the depth of testing analysis; 
i) the TOE suitable for testing. 

12.9.5.3 Action ATE_IND.2.1E 

1 2.9.5.3.1 Work unit 3:ATE_IND.2-1 

ISO/IEC 15408-3 ATE_IND.2. 10: The TOE shall be suitable for testing. 

The evaluator shall examine the TOE to determine that the test configuration is consistent with the 
configuration under evaluation as specified in the ST. 

The TOE used for evaluator testing should have the same unique reference as established by the CM 
capabilities (ACM_CAP).* sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation. The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator's TOE test configurations should be consistent with each evaluated configuration described in 
the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test^nvironment. There may be some assumptions in the ST that do not appty 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that 
these resources are calibrated correctly. 

12.9.5.3.2 Work unit 3:ATE_IND.2-2 

The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state 
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It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous 
successful completion of the ADOJGS.I Installation, generation, and start-up procedures sub-activity will 
satisfy thhs work unit if the evaluator still has confidence that the TGE being used for testing was installed 
properly and is in a known state. If this is not the case, then the evaluator should follow the developer's 
procedures to install, generate and start up the TOE, using the supplied guidance only. 

If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work 
unit when successfully completed could satisfy work unit ADOJGS.I -2. 

1 2.9.5.3.3 Work unit 3:ATEJND.2-3 

ISO/IEC 15408-3 ATEJND.2.2C: The developer shall provide an equivalent set of resources to those that 
were used in the developer's functional testing of the TSF. 

The evaluator shall examine the set of resources provided by the developer to determine that they are 
equivalent to the set of resources used by the developer to functionally test the TSF 

The resource set may include laboratory access and special test equipment, among others. Resources that 
are not identical to those used by the developer need to be equivalent in terms of any impact they may have 
on test results. 

12.9.5.4 Action ATE_IND.2.2E 

12.9.5.4.1 Work unit 3:ATEJND.2-4 

The evaluator shall devise a test subset 

The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing 
strategy would be to have the test subset contain as many security functions as possible tested with little 
rigour. Another testing strategy would be to have the test subset contain a few security functions based on 
their perceived relevance and rigorously test these functions. 

Typically the testing approach taken by the evaluator should fall somewhere between these two extremes. 
The evaluator should exercise most of the security functional requirements identified in the ST using at least 
one test, but testing need not demonstrate exhaustive specification testing. 

The evaluator, when selecting the subset of the TSF to be tested, should consider the following factors: 

a) The developer test evidence. The developer test evidence consists of: the test coverage analysis, the 
depth of testing analysis, and the test documentation. The developer test evidence will provide insight as 
to how the security functions have been exercised by the developer during testing. The evaluator applies 
this information when developing new tests to independently test the TOE. Specifically the evaluator 
should consider: 

1 ) augmentation of developer testing for specific security function(s). The evaluator may wish to perform 
more of the same type of tests by varying parameters to more rigorously test the security function. 

2) supplementation of developer testing strategy for specific security function(s). The evaluator may 
wish to vary the testing approach of a specific security function by testing it using another test 
strategy. 

b) The number of security functions from which to draw upon for the test subset. Where the TOE includes 
only a small number of security functions, it may be practical to rigourously test all of the security 
functions. For TOEs with a large number of security functions this will not be cost-effective, and sampling 
is required. 

c) Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be 
commensurate with that expended on any other evaluation activity. 
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The evaluator selects the security functions to compose the subset. This selection will depend on d number of 
factors, and consideration of these factors may also influence the choice of test subset size: 

a) Rigour of developer testing of the security functions. All security functions identified in the functional 
specification had to have developer test evidence attributed to them as required by ATE_C0V.2 Analysis 
of coverage. Those security functions that the evaluator determines require additional testing should be 
included in the test subset. 

b) Developer test results, tf the results of developer tests cause the evaluator to doubt that a security 
function, or aspect thereof, operates as specified, then the evaluator should include such security 
functions in the test subset. 

c) Known public domain weaknesses commonly associated with the type of TOE (e.g. operating system, 
firewall). Know public domain weaknesses associated with the type of TOE will influence the selection 
process of the test subset. The evaluator should include those security functions that address known 
public domain weaknesses for that type of TOE in the subset (know public domain weaknesses in this 
context does not refer to vulnerabilities as such but to inadequacies or problem areas that have been 
experienced with this particular type of TOE). If no such weaknesses are known, then a more general 
approach of selecting a broad range of security functions may be more appropriate. 

d) Significance of security functions. Those security functions more significant than others in terms of the 
security objectives for the TOE should be included in the test subset. 

e) SOF claims made in the ST. All security functions for which a specific SOF claim has been made should 
be included in the test subset. 

f) Complexity of the security function. Complex security functions may require complex tests that impose 
onerous requirements on the developer or evaluator, which will not be conducive to cost-effective 
evaluations. Conversely, complex security functions are a likely area to find errors and are good 
candidates for the subset. The evaluator will need to strike a balance between these considerations. 

g) Implicit testing. Testing some security functions may often implicitly test other security functions, and their 
inclusion in the subset may maximize the number of security functions tested (albeit implicitly). Certain 
interfaces will typically be used to provide a variety of security functionality, and will tend to be the target 
of an effective testing approach. 

h) Types of interfaces to the TOE (e.g. programmatic, command-line, protocol). The evaluator should 
consider including tests for all different types of interfaces that the TOE supports. 

i) Functions that are innovative or unusual. Where the TOE contains innovative or unusual security 
functions, which may feature strongly in marketing literature, these should be strong candidates for 
testing. 

This guidance articulates factors to consider during the selection process of an appropriate test subset, but 
these are by no means exhaustive. 

For guidance on sampling see A.2, Sampling. 

12.9.5.4.2 Work unit 3:ATE_IND.2-5 

The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the 
tests to be reproducible 

With an understanding of the expected behaviour of a security function, from the ST and the functional 
specification, the evaluator has to determine the most feasible way to test the function. Specifically the 
evaluator considers: 
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a) the approach that will be used, for instance, whether the security function will be tested at an external 
interface, at an internal interface using a test harness, or will an alternate test approach be employed (e.g. 
in exceptional circumstances, a code inspection); 

b) the security function interface(s) that will be used to stimulate the security function and observe 
responses; 

c) the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need 
to exist and security attributes they will need to have); 

d) special test equipment that will be required to either stimulate a security function (e.g. packet generators) 
or make observations of a security function (e.g. network analysers). 

The evaluator may find it practical to test each security function using a series of test cases, where each test 
case will test a very specific aspect of expected behaviour. 

The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant 
design speciftcation, and to the ST, if necessary. 

1 2.9.5.4.3 Work unit 3:ATEJND.2-6 

The evaluator shall conduct testing 

Tke evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test 
documentation is used as a basis for testing but this does not preclude the evaluator from performing 
additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered 
during testing. These new tests are recorded in the test documentation. 

1 2.9.5.4.4 Work unit 3:ATEJND.2-7 

The evaluator shall record the following information about the tests that compose the test subset: 

a) identification of the security function behaviour to be tested; 

b) instructions to connect and setup all required test equipment as required to conduct the test; 

c) instructions to establish alt prerequisite test conditions; 

d) instructions to stimulate the security function; 

e) instructions for observing the behaviour of the security function; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE; 

h) actual test results. 

The level of detail should be such that another evaluator could repeat the tests and obtain an equivalent result. 
While some specific details of the test results may be different (e.g. time and date fields in an audit record) the 
overall result should be identical. 

There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. 
the actual test results of a test may not require any analysis before a comparison between the expected 
results can be made). The determination to omit this information is left to the evaluator, as is the justification. 



162 



1815671:2006 
ISO/IEC 18045: 2005 

12.9.5.4.5 Work unit 3:ATEJND.2-8 

The evaluator shall check that all actual test results are consistent with the expected test results 

Any differences in the actual and expected test results may indicate that the TOE does not perform as 
specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require 
conrective maintenance to the TOE or test documentation and perhaps require re-running of impacted tests 
and modifying the test sample size and composition. This determination is left to the evaluator, as is its 
justification. 

12.9.5.5 Action ATE JND.2.3E 

12.9.5.5.1 Work unit 3:ATEJND.2-9 

The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures 

The overall aim of this work unit is to perform a sufficient number of the developer tests to confirm the validity 
of the developer's test results. The evaluator has to decide on the size of the sample, and the developer tests 
that will compose the sample. . 

Taking into consideration the overall evaluator effort for the entire tests activity, normally 20% of the 
developer's tests should be performed although thig may vary according to the nature of the TOE, and the test 
evidence supplied. 

All the developer tests can be traced back to specific security function(s). Therefore, the factors to consider in 
the selection of the tests to compose the sample are similar to those listed for subset selectlori in work-unit 
ATEJND.2-4. Additionally, the evaluator may wish to employ a random sampling method to select developer 
tests to include in the sariiple. 

For guidance on sampling see A.2, Sampling. 

12.9.5.5.2 Work unit 3:ATEJND.2-10 

The evaluator shaH check that all the actual test results are consistent with the expected test results 

Inconsistencies between the developer's expected test results and actual test results will compel the evaluator 
to resolve the discrepancies. Inconsistencies encountered by the evaluator could be resolved by a valid 
explanation and resolution of the inconsistencies by the developer. 

If a satis^ctory explanation or resolution can not be reached, the evaluator's confidence in the developer's 
test results may be lessened and it may even be necessary for the evaluator to increase the sample size, to 
regain confidence in the developer testing. If the increase in sample size does not satisfy the evaluator's 
concerns, it may be necessary to repeat the entire set of developer's tests. Ultimately, to the extent that the 
TSF subset identified in work unit ATE_IND.2-4 is adequately tested, deficiencies with the developer's tests 
need to result in either corrective action to the developer's tests or in the production of new tests by the 
evaluator. 

12.9.5.5.3 Work unit 3:ATE JND.2-1 1 

The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, 
depth and results 

The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing activity during the evaluation. The intent of providing this 
information is to give a meaningful overview of the testing effort. It is not intended that the information 
regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. 
The intention is to provide enough detail to allow other evaluators and overseers to gain some insight about 
the testing approach chosen, amount of evaluator testing performed, amount of developer tests performed, 
TOE test configurations, and the overall results of the testing activity. 
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Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested. 

b) subset size chosen. The amount of security functions that were tested during the evaluation and a 
justification for the size. 

c) selection criteria for the security functions that compose the subset. Brief statements about the factors 
considered when selecting security functions for inclusion in the subset. 

d) security functions tested. A brief listing of the security functions that merited inclusion in the subset. 

e) developer tests performed. The amount of developer tests performed and a brief description of the criteria 
used to select the tests. 

f) verdict for the activity. The overall judgement on the results of testing during the evaluation. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the testing the evaluator performed during the evaluation. 

12.10 Vulnerability assessment activity 

The purpose of the vulnerability assessment activity is to determine the existence and exploitability of flaws or 
weaknesses in the TOE in the intended environment. This determination is based upon analysis performed by 
the developer and the evaluator, and is supported by evaluator testing. 

12.10.1 Evaluation of IVIisuse (AVA.IMSU.I) 

12.10.1.1 Objectives 

The objectives of this sub-activity are to determine whether the guidance is misleading, unreasonable or 
conflicting, whether secure procedures for all modes of operation have been addressed, and whether use of 
the guidance will facilitate prevention and detection of insecure TOE states. 

12.10.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the test documentation. 

12.10.1.3 Application notes 

The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and 
the secure installation, generation, and start-up procedures. Installation, generation, and start-up procedures 
here refers to all procedures the administrator is responsible to perform to progress the TOE from a delivered 
state to an operational state. 
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12.10.1.4 Action AVA_MSU.1.1E 

12.10.1.4.1 Work unit 3:AVA_IVISU.1-1 

ISO/IEC 15408-3 AVA_MSU.1.1C: The guidance documentation shaii identify all possible modes of operation 
of the TOE (including operation following failure or operational error), their consequences and implications for 
maintaining secure operation. 

The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance 
identifies all possible modes of operation of the TOE (including, if applicable, operation following failure or 
operational error), their consequences and implications for maintaining secure operation. 

Other evaluation evidence, particularly the functional specification and test documentation, provide an 
information source that the evaluator should use to determine that the guidance contains sufficient guidance 
information. 

The evaluator should focus on a single security function at a time, comparing the guidance for securely using 
the security function with other evaluation evidence, to determine that the guidance related to the security 
function is sufficient for the secure usage (i.e. consistent with the TSP) of that security function. The evaluator 
should also consider the relationships between functions, searching for potential conflicts. 

12.10.1.4.2 Work unit3:AVA_IVlSU.1-2 

ISO/IEC 15408-3 AVA_MSU.1.2C: The guidance documentation shall be complete, clear, consistent and 
reasonable. 

The evaluator shall examine the guidance to determine that it is clear and internally consistent. 

The guidance is unclear if it can reasonably be misconstrued by an administrator or user, and used in a way 
detrimental to the TOE, or to the security provided by the TOE. 

For guidance on consistency analysts see A.3, Consistency analysis. 

12.10.1.4.3 Work unit 3:AVA_IVISU.1-3 

The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance is 
complete and reasonable. 

The evaluator should apply familiarity with the TOE gained from performing other evaluation activities to 
determine that the guidance is complete. 

In particular, the evaluator should consider the functional specification and TOE summary specification. All 
security functions described in these documents should be described in the guidance as required to permit 
their secure administration and use. The evaluator may, as an aid, prepare an informal mapping between the 
guidance and these documents. Any omissions in this mapping may Indicate incompleteness. 

The guidance is unreasonable if it makes demands on the TOE's usage or operational environment that are 
inconsistent with the ST or unduly onerous to maintain security. 

The evaluator should note that results gained during the performance of work units from the AGD_ADM sub- 
activity will provide useful input to this examination. 

12.10.1.4.4 Work unit 3:AVA_l\flSU.1-4 

ISO/IEC 15408-3 AVA_MSU.1.3C: The guidance documentation shall list all assumptions about the intended 
environment. 

The evaluator shall examine the guidance to determine that all assumptions about the intended environment 
are articulated. 
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The evaluator analyses the assumptions about the intended TOE security environment of the ST and 
compares them with the guidance to ensure that all assumptions about the intended TOE security 
environment of the ST that are relevant to the administrator or user are described appropriately in the 

guidance. 

12.10.1.4.5 Work unit 3:AVA_MSU.1-5 

ISO/IEC 1 5408-3 AVA_MSU.1 .4C: The guidance documentation sliall list all requirements for external security 
measures (including external procedural, physical antipersonnel controls). 

The evaluator shall examine the guidance to determine that all requirements for external security measures 
are articulated. 

The evaluator analyses the guidance to ensure that it lists all external procedural, physical, personnel and 
connectivity controls. The security objectives in the ST for the non-IT environment will indicate what is 
required. 

12.10.1.5 Action AVA_MSU.1.2E 

12.10.1.5.1 Workunit3:AVA_MSU.1-6 

The evaluator shall perform all administrator and user (if applicable) procedures necessary to configure and 
install the TOE to determine that the TOE can be configured and used securely using only the supplied 
guidance. 

Configuration and installation requires the evaluator to advance the TOE from a deliverable state to the state 
in which the TOE is operational and enforcing a TSP consistent with the security objectives specified in the ST. 

The evaluator should follow only the developer's procedures as documented in the user and administrator 
guidance that is normally supplied to the consumer of the TOE. Any difficulties encountered during such an 
exercise may be indicative of incomplete, unclear, inconsistent or unreasonable guidance. 

Note that work performed to satisfy this work unit may also contribute towards satisfying evaluator action 
AD0JGS.1.2E. 

12.10.1.6 Action AVA_MSU.1.3E 

12.10.1.6.1 Work unit 3:AVA_MSU.1-7 

The evaluator shall examine the guidance to determine that sufficient guidance is provided for the consumer 
to effectively administer and use the TOE's security functions, and to detect insecure states. 

TOEs may use a variety of ways to assist the consumer in effectively using the TOE securely. One TOE may 
employ functionality (features) to alert the consumer when the TOE is in an insecure state, whilst other TOEs 
may be delivered with enhanced guidance containing suggestions, hints, procedures, etc. on using the 
existing security features most effectively; for instance, guidance on using the audit feature as an aid for 
detecting insecure states. 

To arrive at a verdict for this work unit, the evaluator considers the TOE's functionality, its purpose and 
intended environment, and assumptions about its usage or users. The evaluator should arrive at the 
conclusion that, if the TOE can transition into an insecure state, there is reasonable expectation that use of 
the guidance would permit the insecure state to be detected in a timely manner. The potential for the TOE to 
enter into insecure states may be determined using the evaluation deliverables, such as the ST, the functional 
specification and the high-level design of the TSF. 
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12.10.2 Evaluation of Strength of TOE security functions (AVA_SOF.1) 

12.10.2.1 Objectives 

The objectives of this sub-activity are to determiae whether SOF claims are made in the ST for all probabilistic 
or permutational mechanisms and whether the developer's SOF claims made in the ST are supported by an 
analysis that is correct. 

12.10.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the strength of TOE security functions analysis. 

12.10.2.3 Application notes 

SOF analysis is performed on mechanisms that are probabilistic or permutational in nature, such as password 
mechanisms or biometrics. Although cryptographic mechanisms are also probabilistic in nature and are often 
described in terms of strength, AVA_S0F.1 Strength of TOE security function evaluation is not applicable to 
cryptographic mechanisms. For such mechanisms, the evaluator should seek scheme guidance. 

Although SOF analysis is performed on the basis of individual mechanisms, the overall determination of SOF 
is based on functions. Where more than one probabilistic or permutational mechanism is employed to provide 
a security function, each distinct mechanism must be analysed. The manner in which these mechanisms 
combine to provide a security function will determine the overall SOF level for that function. The evaluator 
needs design information to understand how the mechanisms work together to provide a function, and a 
minimum level for such information is given by the dependency on ADV_HLD.1 Descriptive high-level design. 
The actual design information available to the evaluator is determined by the EAL, and the available 
information should be used to support the evaluator's analysis when required. 

For a discussion on SOF in relation to multiple TOE domains see subclause Evaluation of IT security 
requirements (ASE_REQ.1). 

12.10.2.4 Action AVA_S0F.1.1E 

12.10.2.4.1 Work unit 3:AVA_S0F.1-1 

ISO/IEC 15408-3 AVA_S0F.1.1C: For each mechanism with a strength of TOE security function claim the 
strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level 
defined in the PP/ST. 

The evaluator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim in the ST expressed as a SOF rating. 

If SOF claims are expressed solely as SOF metrics, then this work unit Is not applicable and is therefore 
considered to be satisfied. 

A SOF rating is expressed as one of SOF-bastc, SOF-medium or SOF-high, which are defined in terms of 
attack potential - refer to ISO/IEC 15408-1 clause 2. A minimum overall SOF requirement expressed as a 
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rating applies to all non-cryptographic, probabilistic or permutational security mechanisms. However, 
Individual mechanisms may have a SOF claim expressed as a rating that exceeds the overall SOF 
requirement. 

Guidarice on determining the attack potential necessary to effect an attack and, hence, to determine SOF as a 
rating is in A.8. Strength of function and vulnerability analysis. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

12.10.2.4.2 Work unit 3:AVA_SOF.1-2 

ISO/IEC 1 5408-3 AVA_S0F.1 .2C: For each mechanism with a specific strength of TOE security function claim 
the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of 
function metric defined in the PP/ST. 

The evaluator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim in the ST expressed as a metric. 

If SOF claims are expressed solely as SOF ratings, then this work unit is not applicable and is therefore 
considered to be satisfied. 

A minimum overall SOF requirement expressed as a rating applies to ail non-cryptographic, probabilistic or 
permutational mechanisms. However, individual mechanisms may have a SOF jclaim expressed as a metric 
that meets or exceeds the overall SOF requirement. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

12.10.2.4.3 Work unit 3:AVA_SOF.1-3 

The evaluator shall examine the SOF analysis to determine that any assertions or assumptions supporting the 
analysis are valid. 

For example, it may be a flawed assumption that a particular implementation of a pseudo-random number 
generator will possess the required entropy necessary to seed the security mechanism to which the SOF 
analysis is relevant. 

Assumptions supporting the SOF analysis should reflect the worst case, unless worst case is invalidated by 
the ST. Where a number of different possible scenarios exist, and these are dependent on the behaviour of 
the human user or attacker, the case that represents the lowest strength should be assumed unless, as 
previously stated, this case is invalid. 

For example, a strenigth claim based upon a maximum theoretical password space (i.e. all printable ASCII 
characters) would not be worst case because it is human behaviour to use natural language passwords, 
effectively reducing the password space and associated strength. However, such an assumption could be 
appropriate if the TOE used IT measures, identified in the ST, such as password filters to minimise the use of 
natural language passwords. 

12.10.2.4.4 Work unit 3:AVA_SOF.1-4 

The evaluator shall examine the SOF analysis to determine that any algorithms, principles, properties and 
calculations supporting the analysis are correct. 

The nature of this work unit is highly dependent upon the type of mechanism being considered. A.8, Strength 
of function and vulnerability analysis, provides an example SOF analysis for an identification and 
authentication function that is implemented using a password mechanism; the analysis considers the 
maximum password space to ultimately arrive at a SOF rating. For biometrics, the analysis should consider 
resolution and other factors impacting the mechanism's susceptibility to spoofing. 
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SOF expressed as a rating is based on the minimum attacl< potential required to defeat the security 
mechanism. The SOF ratings are defined in terms of attack potential in ISO/IEC 15408-1 clause 2. 

For guidance on attack potential see A.8, Strength of function and vulnerability analysis. 

12.10.2.4.5 Work unit3:AVA_SOF.1-5 

The evaluator shall examine the SOF analysis to determine that each SOF claim is met or exceeded. 
For guidance on the rating of SOF claims see A.8, Strength of function and vulnerability analysis. 

12.10.2.4.6 Work unit 3:AVA_SOF.1-6 

The evaluator shall examine the SOF analysis to determine that all functions with a SOF claim meet the 
minimum strength level defined in the ST. 

12.10.2.5 Action AVA_S0F.1.2E 

12.10.2.5.1 Workunit3:AVA_SOF.1-7 

The evaluator shall examine the functional specification, the high-level design, the low-level design, the user 
guidance and the administrator guidance to determine that all probabilistic or permutational mechanisms have 
a SOF claim. 

The identification by the developei" of security functions that are realised by probabilistic or permutational 
mechanisms is verified during the ST evaluation. However, because the TOE summary specification may 
have been the only evidence available upon which to perform that activity, the identification of such 
mechanisms may be incomplete. Additional evaluation evidence required as input to this sub-activity may 
identify additional probabilistic or permutational mechanisms not already identified in the ST. If so, the ST will 
have to be updated appropriately to reflect the additional SOF claims and the developer will need to provide 
additional analysis that justifies the claims as input to evaluator action AVA_S0F.1 .1E. 

12.10.2.5.2 Work unit3:AVA_SOF.1-8 

The evaluator shall examine the SOF claims to determine that they are correct. 

Where the SOF analysis includes assertions or assumptions (e.g. about how many authentication attempts 
are possible per minute), the evaluator should independently confirm that these are correct. This may be 
achieved through testing or through independent analysis. 

12.10.3 Evaluation of Vulnerability analysis (AVA_VLA.1) 

12.10.3.1 Objectives 

The objective of this sub-activity is to determine whether the TOE, in its intended environment, has exploitable 
obvious vulnerabilities. 

12.10.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 
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e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the vulnerability analysis; 

h) the strength of function claims analysis; 

i) the TOE suitable for testing. 

Other input for this sub-activity is: 

a) current information regarding obvious vulnerabilities (e.g. from an overseer). 

12.10.3.3 Application notes 

The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and 
the secure installation, generation, and start-up procedures. 

The consideration of exploitable vulnerabilities will be determined by the security objectives and functional 
requirements in the ST. For example, if measures to prevent bypass of the security functions are not required 
in the ST (TSF physical protection (FPT_PHP), Reference mediation (FPT_RVM) and Domain separation 
(FPT_SEP) are absent) then vulnerabilities based on bypass should not be considered. 

Vulnerabilities may be in the public domain, or not, and may require skill to exploit, or not. These two aspects 
are related, but are distinct. It should not be assumed that, simply because a vulnerability is in the public 
domain, it can be easily exploited. 

The following terms are used in the guidance with specific meaning: 

a) Vulnerability - a weakness in the TOE that can be used to violate a security policy in some environment; 

b) Vulnerability analysis - A systematic search for vulnerabilities in the TOE, and an assessment of those 
found to determine their relevance for the intended environment for the TOE; 

c) Obvious vulnerability - a vulnerability that is open to exploitation that requires a minimum of 
understanding of the TOE, technical sophistication and resources; 

d) Potential vulnerability - A vulnerability the existence of which is suspected (by virtue of a postulated attack 
path), but not confirmed, tn the TOE; 

e) Exploitable vulnerability - A vulnerability that can be exploited in the intended environment for the TOE; 

f) Non-explditable vulnerability - A vulnerability that cannot be exploited In the intended environment for the 
TOE; 

g) Residual vulnerability - A non-exploitable vulnerability that could be exploited by an attacker with greater 
attack potential than is anticipated in the intended environment for the TOE; 

h) Penetration testing - Testing carried out to determine the exploitability of identified TOE potential 
vulnerabilities in the intended environment for the TOE. 

12.10.3.4 Action AVA_VLA.1. IE 

12.10.3.4.1 Work unit 3:AVA_VI_A.1-1 

ISO/IEC 15408-3 AVA_VLA.1.1C: The vulnerability analysis documentation shall describe the analysis of the 
TOE deliverables performed to search for obvious ways in which a user can violate the TSP, 
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ISO/IEC 15408-3 AVA_VLA.1.2C: The vulnerability analysis documentation shall describe the disposition of 
obvious vulnerabilities. 

ISO/IEC 15408-3 AVA_VLA,1.3C: The vulnerability analysis documentation shall show, for all identified 
vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. 

The evaluator shall examine the developer's vulnerability analysis to determine that the search for obvious 
vulnerabilities has considered all relevant information. 

The developer's vulnerability analysis should cover the developer's search for obvious vulnerabilities in at 
least all evaluation deliverables and public domain information sources. The evaluator should use the 
evaluation deliverables, not to perform an independent vulnerability analysis (not required at AVA_VLA.1 
Developer vulnerability analysis), but as a tiasis for assessing the developer's search for obvious 
vulnerabilities. 

Information in the public domain is highly dynamic. Therefore, it is possible that new vulnerabilities are 
reported in the public domain between the time the developer performs the vulnerability analysis and the time 
that the evaluation is completed. The point at which monitoring of the public domain information ceases is an 
evaluation authority issue; therefore guidance and agreement should be sought from the evaluation authority. 

12.10.3.4.2 Work unit3:AVA_VLA.1-2 

The evaluator shall examine the developer's vulnerability analysis to determine that each obvious vulnerability 
is described and that a rationale is given for why it is not exploitable in the intended environment for the TOE. 

The developer is expected to search for obvious vulnerabilities, based on knowledge of the TOE, and of public 
domain information sources. Given the requirement to identify only obvious vulnerabilities, a detailed analysis 
is not expected. The developer filters this information, based on the above definition, and shows that obvious 
vulnerabilities are not exploitable in the intended environment. 

The evaluator needs to be concerned with three aspects of the developer's analysis: 

a) whether the developer's analysis has considered all evaluation deliverables; 

b) whether appropriate measures are in place to prevent the exploitation of obvious vulnerabilities in the 
intended environment; 

c) whether some obvious vulnerabilities remain unidentified. 

The evaluator should not be concerned over whether identified vulnerabilities are obvious or not, unless this is 
used by the developer as a basis for determining non-exploitability. In such a case the evaluator validates the 
assertion by determining resistance to an attacker with low attack potential for the identified vulnerability. 

The concept of obvious vulnerabilities is not related to that of attack potential. The latter is determined by the 
evaluator during independent vulnerability analysis. Since this activity is not performed for AVA_VLA.1 
Developer vulnerability analysis, there is normally no searching and filtering by the evaluator on the basis of 
attack potential. However, the evaluator may still discover potential vulnerabilities during the evaluation, and 
the determination of how these should be addressed will be made by reference to the definition of obvious 
vulnerabilities and the concept of low attack potential. 

The determination as to whether some obvious vulnerabilities remain unidentified is limited to assessment of 
the validity of the developer's analysis, a comparison with available public domain vulnerability information, 
and a comparison with any further vulnerabilities identified by the evaluator during the course of other 
evaluation activities. 

A vulnerability is termed non-exploitable if one or more of the following conditions exist: 
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a) security functions.or measures in the (IT or non-IT) environment prevent exploitation of the vulnerability in 
the intended environment. For instance, restricting physical access to the TOE to authorised users only 
may effectively render a TOE's vulnerability to tampering unexploitable; 

b) the vulnerability is exploitable but only by attackers possessing moderate or high attack potential. For 
instance, a vulnerability of a distributed TOE to session hijack attacks requires an attack potential beyond 
that required to exploit an obvious vulnerability. However, such vulnerabilities are reported in the ETR as 
residual vulnerabilities. 

c) either the threat is not claimed to be countered or the violable organisational security policy is not claimed 
to be achieved by the ST. For instance, a firewall whose ST makes no availability policy claim and is 
vulnerable to TCP SYN attacks (an attack on a common Internet protocol that renders hosts incapable of 
servicing connection requests) should not fail this evaluator action on the basis of this vulnerability alone. 

For guidance on determining attack potential necessary to exploit a vulnerability see A.8, Strength of function 
and vulnerability analysis. 

12.10.3.4.3 Work unit3:AVA_VLA.1-3 

The evaluator shall examine the developer's vulnerability analysis to determine that it is consistent with the ST 
^nd the guidance. 

The developer's vulnerability analysis may address a vulnerability by suggesting specific configurations or 
settings for TOE functions. If such operating constraints are deemed to be effective and consistent with the ST, 
then all such configurations/settings should be adequately described in the guidance so that they may be 
employed by the consumer. 

12.10.3.5 Action AVA_VLA.1.2E 

12.10.3.5.1 Workunit3:AVA_VLA.1-4 

The evaluator shall devise penetration tests, building on the developer vulnerability analysis. 
The evaluator prepares for penetration testing: 

a) as necessary to attempt to disprove the developer's analysis in cases where the developer's ration^ale for 
why a vulnerability is unexploitable is suspect in the opinion of the evaluator; 

b) as necessary to determine the susceptibility of the TOE, in its intended environment, to an obvious 
vulnerability not considered by the developer. The evaluator should have access to current information 
(e.g. from the overseer) regarding obvious public domain vulnerabilities that may not have been 
considered by the developer, and may also have identified potential vulnerabilities as a result of 
performing other evaluation activities. 

The evaluator is not expected to test for vulnerabilities (including those in the public domain) beyond those 
which are obvious. In some cases, however, it will be necessary to carry out a test before the exploitability can 
be determined. Where, as a result of evaluation expertise, the evaluator discovers a vulnerability that is 
beyond obvious, this is reported in the ETR as a residual vulnerability. 

With an understanding of the suspected obvious vulnerability, the evaluator determines the most feasible way 
to test for the TOE's susceptibility. Specifically the evaluator considers: 

a) the security function interfaces that will be used to stimulate the TSF and observe responses; 

b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to 
exist and security attributes they will need to have); 
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c) special test equipment that will be required to either stimulate a security function or make observations of 
a security function (although it is unlikely that specialist equipment would be required to exploit an 
obvious vulnerability). 

The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where 
each test case will test for a specific obvious vulnerability. 

12.10.3.5.2 Work unit 3:AVA_VLA.1-5 

The evaluator shall produce penetration test documentation for the tests that build upon the developer 
vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall 
include: 

a) identification of the obvious vulnerability the TOE is being tested for; 

b) instructions to connect and setup all required test equipment as required to conduct the penetration test; 

c) instructions to establish all penetration test prerequisite initial conditions; 

d) instructions to stimulate the TSF; 

e) instructions for observing the behaviour of the TSF; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE. 

The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the 
tests and obtain an equivalent result. 

12.10.3.5.3 Workunlt3:AVA_VLA.1-6 

The evaluator shall conduct penetration testing, building on the developer vulnerability analysis. 

The evaluator uses the penetration test documentation resulting from work unit AVA_VLA.1-4 as a basis for 
executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad 
hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learned 
during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test 
documentation. Such tests may be required to follow up unexpected results or observations, or to investigate 
potential vulnerabilities suggested to the evaluator during the pre-planned testing. 

12.10.3.5.4 Work unit 3:AVA_VLA.1-7 

The evaluator shall record the actual results of the penetration tests. 

While some specific details of the actual test results may be different from those expected (e.g. time and date 
fields in an audit record) the overall result should be identical. Any differences should be justified. 

12.10.3.5.5 Work unit 3:AVA_VLA.1-8 

The evaluator shall examine the results of all penetration testing and the conclusions of all vulnerability 
analysis to determine that the TOE, in its intended environment, has no exploitable obvious vulnerabilities. 

If the results reveal that the TOE has obvious vulnerabilities, exploitable in its intended environment, then this 
results in a failed verdict for the evaluator action. 
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12.10.3.5.6 Work unit3:AVA_VLA.1-9 

The evaluator shall report In the ETR the evaluator penetration testing effort, outlining the testing approach, 
configuration, depth and results. 

The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration 
testing approach and effort expended on this sub-activity. The intent of providing this information is to give a 
meaningful overview of the evaluator's penetration testing effort. It is not intended that the information 
regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual 
penetration tests. The intention is to provide enough detail to allow other evaluators and overseers to gain 
some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE 
test configurations, and the overall results of the penetration testing activity. 

Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts 

is: 

a) TOE test configurations. The particular configurations of the TOE that were penetration tested; 

b) security functions penetration tested. A brief listing of the security functions that were the focus of the 
penetration testing; 

c) verdict for the sub-activity. The overall judgement on the results of penetration testing. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the penetration testing the evaluator performed during the 
evaluation. 

12.10.3.5.7 Wofk unit 3:AVA_VLA.1 -10 

The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for 
each: 

a) its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the 
evaluator, read in a publication); 

b) the implicated security function(s), objective(s) not met, organisational security policy(ies) contravened 
and threat(s) realised; 

c) a description; 

d) whether it is exploitable in its intended environment or not (i.e. exploitable or residual); 

e) identification of evaluation party (e.g. developer, evaluator) who identified it. 

13 EAL4 evaluation 

13.1 Introduction 

EAL4 provides a moderate to high level of assurance. The security functions are analysed using a functional 
specification, guidance documentation, the high-level and low-level design of the TOE, and a subset of the 
implementation to understand the security behaviour. The analysis is supported by independent testing of a 
subset of the TOE security functions, evidence of developer testing based on the functional specification and 
the high level design, selective confirmation of the developer test results, analysis of strengths of the functions, 
evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating 
resistance to low attack potential penetration attackers. Further assurance is gained through the use of an 
informal model of the TOE security policy and through the use of development environment controls, 
automated TOE configuration management, and evidence of secure delivery procedures. 
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13.2 Objectives 



The objective of this clause is to define the minimal evaluation effort for achieving an EAL4 evaluation and to 
provide guidance on ways and means of accomplishing the evaluation. 

13.3 EAL4 evaluation relationships 

An EAL4 evaluation covers the following: 

a) evaluation input task (Clause 7); 

b) EAL4 evaluation activities comprising the following: 

1) evaluation of the ST (Clause 9); 

2) evaluation of the configuration management (Subclause 1 3.4); 

3) evaluation of the delivery and operation documents (Subclause 13.5); 

4) evaluation of the development documents (Subclause 1 3.6); 

5) evaluation of the guidance documents (Subclause 13.7); 

6) evaluation of the life cycle support (Subclause 13.8); 

7) evaluation of the tests (Subclause 13.9); 

8) testing (Subclause 13.9); 

9) evaluation of the vulnerability assessment (Subclause 13.10); 

c) evaluation output task (Clause 7). 

The evaluation activities are derived from the EAL4 assurance requirements contained in ISO/IEC 15408-3. 

The ST evaluation is started prior to any TOE evaluation sub-activities since the ST provides the basis and 
context to perform these sub-activities. 

The sub-activities comprising an EAL4 evaluation are described in this clause. Although the sub-activities can, 
in general, be started more or less coincidentally, some dependencies between sub-activities have to be 
considered by the evaluator. 

For guidance on dependencies see Annex A 

13.4 Configuration managennent activity 

The purpose of the configuration management activity is to assist the consumer in identifying the evaluated 
TOE, to ensure that configuration items are uniquely identified, and the adequacy of the procedures that are 
used by the developer to control and track changes that are made to the TOE. This includes details on what 
changes are tracked, how potential changes are incorporated, and the degree to which automation is used to 
reduce the scope for error. 

13.4.1 Evaluation of CM automation (ACM_AUT.1) 

13.4.1.1 Objectives 

The objective of this sub-activity is to determine whether changes to the implementation representation are 
controlled with the support of automated tools, thus making the CM system less susceptible to human error or 
negligence. 
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13.4.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the configuration nnanagement documentation. 

13.4.1.3 Action ACM_AUT.1. IE 

13.4.1.3.1 Work unit 4:ACM_AUT.1-1 

ISO/IEC 15408-3 ACM_AUT.1.1C: The CM system shall provide an automated means by which only 
authorised changes are made to the TOE implementation representation. 

The evaluator shall check the CM plan for a description of the automated measures to control access to the 
TOE implementation representation. 

1 3.4.1 .3.2 Work unit 4:ACM_AUT.1 -2 

The evaluator shall examine the automated access control measures to determine that they are effective in 
preventing unauthorised modification of the TOE implementation representation. 

The evaluator reviews the configuration management documentation to identify those Individuals or roles 
authorised to make changes to the TOE implementation representation. For example, once it is under 
configuration management, access to an element of the implementation representation may only be allowed 
for the individual who performs the software integration role. 

Th« evaluator should exercise the automated access control measures to determine whether they can be 
bypassed by an unauthorised role or user. This determination need only comprise a few basic tests. 

13.4.1.3.3 Work unit4:ACM_AUT.1-3 

ISO/IEC 15408-3 ACM_AUT.1.2C: The CM system shall provide an automated means to support the 
generation of the TOE. 

The evaluator shalf check the CM documentation for automated means to support generation of the TOE from 
its implementation representation. 

In this work unit the term "generation" applies to those processes adopted by the developer to progress the 
TOE from its implementation to a state ready to be delivered to the end customer. 

The evaluator should verify the existence of automated generation support procedures within the CM 
documentation. 

13.4.1.3.4 Work unit 4:ACM_AUT.1-4 

The evaluator shall examine the automated generation procedures to determine that they can be used to 
support generation of the TOE. 

The evaluator determines that by following the generation procedures a TOE would be generated that reflects 
its implementation representation. The customer can then be confident that the version of the TOE delivered 
for installation implements the TSP as described in the ST. For example, in a software TOE this may include 
checking that the automated generation procedures help to ensure that all source files and related libraries 
that are relied upon to enforce the TSP are included in the compiled object code. 

It should be noted that this requirement is only to provide support. For example, an approach that placed Unix 
makefiles under configuration management should be sufficient to meet the aim, given that in such a case 
automation would have made a significant contribution to accurate generation of the TOE. Automated 
procedures can assist in identifying the correct configuration items to be used in generating the TOE. 
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13.4.1.3.5 Workunit4:ACM_AUT.1-5 

ISO/IEC 1 5408-3 ACM_AUT.1 .3C: The CM plan shall describe the automated tools used in the CM systen). 

The evaluator shall check that the CM plan includes information on the automated tools used in the CM 
system. 

1 3.4.1 .3.6 Work unit 4:ACM_AUT.1 -6 

iSO/tEC 15408-3 ACM_AUT.1.4C: The CM plan shall describe how the automated tools are used in the CM 
system. 

The evaluator shall examine the information relating to the automated tools provided in the CM plan to 
determine that it describes how they are used. 

The information provided in the CM plan provides the necessary detail for a user of the CM system to be able 
to operate the automated tools correctly in order to maintain the integrity of the TOE. For example, the 
information provided may include a description of: 

a) the functionality provided by the tools; 

b) how this functionality is used by the developer to control changes to the implementation representation; 

c) how this functionality is used by the developer to support generation of the TOE. 
13.4.1.4 Implied evaluator action 

13.4.1.4.1 Workunit4:ACM_AUT.1-7 

iSO/IEC 15408-3 ACM_AUT.1 .ID: The developer shall use a CM system. 

The evaluator shall examine the CM system to determine that the automated tools and procedures described 
in the CM plan are used. 

This work unit may be viewed as an additional activity to be carried out in parallel with the evaluator's 
examination into the use of the CM system required by CM capabilities (ACM_CAP). The evaluator looks for 
evidence that the tools and procedures are in use. This should include a visit to the development site to 
witness operation of the tools and procedures, and an examination of evidence produced through their use. 

For guidance on site visits see A.5, Site Visits. 

13.4.2 Evaluation of CIVI capabilities (ACM_CAP.4) 

13.4.2.1 Objectives 

The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE and 
its associated configuration items, and whether the ability to modify these items is properly controlled. 

13.4.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the TOE suitable for testing; 

c) the configuration management documentation. 
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13.4.2.3 Action ACM_CAP.4.1E 

13.4.2.3.1 Work unit 4:ACM_CAP.4-1 

ISO/IEC 15408-3 ACM_CAP.4.1C: The reference for the TOE shall be unique to each version of the TOE. 

The evaluator shall check that the version of the TOE provided for evaluation is uniquely referenced. 

The evaluator should use the developer's CM system to validate the uniqueness of the reference by checking 
the configuration list to ensure that the configuration items are uniquely identified. Evidence that the version 
provided for evaluation is uniquely referenced may be incomplete if only one version is examined during the 
evaluation, and the evaluator should look for a referencing system that is capable of supporting unique 
references (e.g. use of numbers, letters or dates). However, the absence of any reference will normally lead to 
a fail verdict against this requirement unless the evaluator is confident that the TOE can be uniquely identifed. 

The evaluator should seek to examine more than one version of the TOE (e.g. during rework following 
discovery of a vulnerability), to check that the two versions are referenced differently. 

1 3.4.2.3.2 Work unit 4:ACM_CAP.4-2 

ISO/IEC 1 5408-3 ACM_CAP.4.2C; The TOE shall be labelled with its reference. 

The evaluator shall check that the TOE provided for evaluation is labelled with its reference. 

The evaluator should ensure that the TOE contains a unique reference such that it is possible to distinguish 
different versions of the TOE. This could be achieved through labelled packaging or media, or by a label 
displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the 
TOE (e.g. at the point of purchase or use). 

The TOE may provide a method by which it can be easily identified. For example, a software TOE may display 
its name and version number during the start up routine, or in response to a command line entry. A hardware 
or firmware TOE may be identified by a part number physically stamped on the TOE. 

13.4.2.3.3 Work unit 4:ACM_CAP.4-3 

The evaluator shall check that the TOE references used are consistent. 

If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible 
to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. 
This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, 
that they have installed this version, and that they have the correct version of the guidance to operate the TOE 
in accordance with its ST. The evaluator can use the configuration list that is part of the provided CM 
documentation to verify the consistent uset)f identifiers. 

The evaluator also verifies that the TOE reference is consistent with the ST. 

For guidance on consistency analysis see A.3, Consistency analysis. 

13.4.2.3.4 Work unit 4:ACM_CAP.4-4 

ISO/IEC 154U8-3 ACM_CAP.4.3C: The CM documentation shall include a configuration list, a CM plan, and 
an acceptance plan. 

The evaluator shall check that the CM documentation provided includes a configuration list. 

A configuration list identifies the items being maintained under configuration control. 
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13.4.2.3.5 Work unit 4:ACM_CAP.4-5 

The evaluator shall check that the CM documentation provided includes a CM plan. 

13.4.2.3.6 Work unit 4:ACM_CAP.4-6 

The evaluator shall check that the CM documentation provided includes an acceptance plan. 

1 3.4.2.3.7 Work unit 4:ACM_CAP.4-7 

ISO/IEC 15408-3 ACM_CAP.4.4C: The configuration list stiall uniquely identify all configuration items that 
comprise the TOE. 

The evaluator shall check that the configuration list uniquely Identifies each configuration item. 

The configuration list contains a list of the configuration items that comprise the TOE, together with sufficient 
information to uniquely identify v*/hich version of each item has been used (typically a version number). Use of 
this list will enable the evaluator to check that the correct configuration items, and the correct version of each 
item, have been used during the evaluation. 

13.4.2.3.8 Work unit 4:ACIVI_CAP.4-8 

ISO/IEC 15408-3 ACM_CAP.4.5C: The configuration list shall describe the configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration list to determine that it identifies the configuration items that 
comprise the TOE. 

The minimum scope of configuration items to be covered in the configuration list is given by CM scope 
(ACM_SCP). 

13.4.2.3.9 Work unit 4:ACM_CAP.4-9 

ISO/IEC 1 5408-3 ACM_CAP.4.6C: The CM documentation shall describe the method used to uniquely identify 
the configuration items that comprise the TOE. 

The evaluator shall examine the method of identifying configuration items to determine that it describes how 
configuration items are uniquely identified. 

13.4.2.3.10 Work unit4:ACIVI_CAP.4-10 

ISO/IEC 15408-3 ACM_CAP.4.7C: The CM system shall uniquely identify all configuration items that comprise 
the TOE. 

The evaluator shall examine the configuration items to determine that they are identified in a way that is 
consistent with the CM documentation. 

Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers 
for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration 
items that are submitted by the developer as evaluation evidence, the evaluator confirms that each 
configuration item possesses a unique identifier in a manner consistent with the unique identification method 
that is described in the CM documentation. 

1 3.4.2.3.1 1 Work unit 4:ACI«_C AP.4-1 1 

ISO/IEC 15408-3 ACM_CAP.4.8C: The CM plan shall describe how the CM system is used. 

The evaluator shall examine the CM plan to determine that it describes how the CM system is used to 
maintain the integrity of the TOE configuration items. 
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The descriptions contained in a CM plan may include: 

a) all activities performed in the TOE development environment that are subject to configuration 
management procedures (e.g. creation, modification or deletion of a configuration item); 

b) the roles and responsibilities of individuals required to perform operations on individual configuration 
items (different roles may be identified for different types of configuration item (e.g. design documentation 
or source code)); 

c) the procedures that are used to ensure that only authorised individuals can make changes to 
configuration items; 

d) the procedures that are used to ensure that concurrency problems do not occur as a result of 
simultaneous changes to configuration items; 

e) the evidence that is generated as a result of application of the procedures. For example, for a change to a 
configuration item, the CM system might record a description of the change, accountability for the change, 
identification of all configuration items affected, status (e.g. pending or completed), and date and time of 
the change. This might be recorded in an audit trail of changes made or change control records; 

f) the approach to version control and unique referencing of TOE versions (e.g. covering the release of 
patches in operating systems, and the subsequent detection of their application). 

13.4.2.3.12 Work unit4:ACM_CAP.4-12 

ISO/lEC 15408-3 ACM_CAP.4.9C: The evidence shall demonstrate that the CM system is operating in 
accordance with the CM plan. 

The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified 
by the CM plan. 

The output produced by the CM system should provide the evidence that the evaluator needs to be confident 
that the CM plan is being applied, and also that all configuration items are being maintained by the CM system 
as required by ACM_CAP.4.10C. Example output could include change control forms, or configuration item 
access approval forms. 

13.4.2.3.13 Work unit4:ACM_CAP.4-13 

The evaluator shall examine the evidence to determine that the CM system is being used as it is described in 
the CM plan. 

The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation 
that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier 
version) to confirm that all operations of the CM system have been carried out in line with documented 
procedures. The evaluator confirms that the evidence includes ail the information identified for that operation 
in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may 
choose to saniple the evidence. 

For guidance on sampling see A.2, Sampling. 

Further confidence in the correct operation of the CM system and the effective maintenance of configuration 
items may be established by means of interview with selected development staff. In conducting such 
interviews, the evaluator should aim to gain a deeper understanding of how the CM system is used in practice 
as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note 
that such interviews should complement rather than replace the examination of documentary evidence, and 
may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide 
scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from 
the CM plan and records alone. This is one case where clarification may be necessary through interviews. 
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It is expected that the evaluator will visit the development site in support of this activity. 
For guidance on site visits see A.5, Site Visits. 

13.4.2.3.14 Work unit4:ACM_CAP.4-14 

ISO/IEC 16408-3 ACM_CAP.4.10C: The CM documentation shall provide evidence that all configui^tion items 
have been and are being effectively maintained under the CM system. 

The evaluator shall check that the configuration items identified in the configuration list are being maintained 
by the CM system. 

The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should 
check that for each type of configuration item (e.g. high-level design or source code modules) contained in the 
configuration list there are examples of the evidence generated by the procedures described in the CM plan. 
In this case, the approach to sampling will depend upon the level of granularity used in the CM system to 
control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a 
different sampling strategy should be applied compared to the case in which there are only 5, or even 1 . The 
emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on 
the detection of any minor error. 

For guidance on sampling see A.2, Sampling. 

13.4.2.3.15 Work unit4:ACM_CAP,4-15 

ISO/IEC 15408-3 ACM_CAP.4.11C: The CM system shall provide measures such that only authorised 
changes are made to the configuration items. 

The evaluator shall examine the CM access control measures described in the CM plan to determine that they 
are effective in preventing unauthorised access to the configuration items. 

The evaluator may use a number of methods to determine that the CM access control measures are effective. 
For example, the evaluator may exercise the access control measures to ensure that the procedures could not 
be bypassed. The evaluator may use the outputs generated by the CM system procedures and already 
examined as part of the work unit ACM_CAP.4-13. The evaluator may also witness a demonstration of the CM 
system to ensure that the access control measures employed are operating effectively. 

The developer will have provided automated access control measures as part of the CM system and as such 
their suitability may be verified under the component ACM_AUT.1 Partial CM automation. 

13.4.2.3.16 Work unit4:ACM_CAP,4-16 

ISO/IEC 15408-3 ACM_CAP.4.12C: The CM system shall support the generation of tire TOE. 

The evaluator shall check the CM documentation for procedures for supporting the generation of the TOE. 

In this work unit the term "generation" applies to those processes adopted by the developer to progress the 
TOE from implementation to a state acceptable for delivery to the end customer. 

The evaluator verifies the existence of generation support procedures within the CM documentation. The 
generation support procedures provided by the developer may be automated, and as such their existence 
may be verified under the component ACM_AUT.1.2C. 

13.4.2.3.17 Work unit4:ACM_CAP.4-17 

The evaluator shall examine the TOE generation procedures to determine that they are effective in helping to 
ensure that the correct configuration items are used to generate the TOE. 



181 



IS 15671 : 2006 
ISO/IEC 18045: 2005 

The evaluator determines that by following the generation support procedures the versior\ of the TOE 
expected by the customer (i.e. as described in the TOE ST and consisting of the correct configuration items) 
would be generated and delivered for installation at the customer site. For example, in a software TOE this 
may include checking that the procedures ensure that all source files and related libraries are included in the 
compiled object code. 

The evaluator should bear in mind that the CM system need not necessarily possess the capability to 
generate the TOE, but should provide support for the process that will help reduce the probability of human 
error. 

13.4.2.3.18 Work unit4:ACM_CAP.4-18 

ISO/IEC 15408-3 ACM_CAP.4.13C: The acceptance plan shall describe the procedures used to accept 
modified or newly created configuration items as part of the TOE: 

The evaluator shall examine the acceptance procedures to determine that they describe the acceptance 
criteria to be applied to newly created or modified configuration items. 

An acceptance plan describes the procedures that are to be used to ensure that the constituent parts of the 
TOE ^re of adequate quality prior to incorporation into the TOE. The acceptance plan should identify the 
acceptance procedures to be applied: 

a) at each stage of the construction of the TOE (e.g. module, integration, system); 

b) to the acceptance of software, firmware and hardware components; 

c) to the acceptance of previously evaluated components. 

The description of the acceptance criteria may include identification of: 

a) developer roles or individuals responsible for accepting such configuration items; 

b) any acceptance criteria to be applied before the configuration items are accepted (e.g. successful 
document review, or successful testing in the case of software, firmware or hardware). 

13.4.3 Evaluation of CM scope (ACM_SCP.2) 

13.4.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer performs configuration management 
on the TOE implementation representation, design, tests, user and administrator guidance, the CM 
documentation and security flaws. 

13.4.3.2 Input 

The evaluation evidence for this sub-activity is: 
a) the configuration item list. 

13.4.3.3 Action ACBfl_SCP.2.1E 

13.4,3.3.1 WoEkunit4:ACM_SCP.2-1 

ISO/IEC 15408-3 ACM_SCP.2.1C: The list of configuration items shall include the following: implementaUon 
representation; security flaws; and the evaluation evidence required by the assurance components in the ST. 

The evaluator shall check that the configuration item list includes the set of items required by ISO/IEC 15408. 
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The list includes the following: 



a) the TOE implementation representation (i.e.. the components or subsystems that compose the TOE). For 
a software-only TOE, the implementation representation may consist solely of source code; for a TOE 
that includes a hardware platform, the implementation representation may refer to a combination of 
software, firmware and a description of the hardware. 

b) the evaluation evidence required by the assurance components in the ST. 

c) the documentation used to record details of reported security flaws associated with the implementation 
(e.g., problem status reports derived from a developer's problem database). 

13.5 Delivery and operation activity 

The purpose of the delivery and operation activity is to judge the adequacy of the documentation of the 
procedures used to ensure that the TOE is installed, generated, and started in the same way the developer 
intended it to be and that it is delivered without modification. This includes t)Oth the procedures taken while the 
TOE is in transit, as well as the initialisation, generation, and start-up procedures. 

13.5.1 Evaluation of Delivery (AD0_DEL.2) 

13.5.1.1 Objectives 

The objective of this sub-activity is to determine whether the delivery documentation describes all procedures 
used to maintain security and detect modification or substitution of the TOE when distributing the TOE to the 
user's site. 

13.5.1.2 Input 

The evaluation evidence for this sub-activity is: 
a) the delivery documentation. 

13.5.1.3 Action AD0_DEL.2.1E 

13.5.1 .3.1 Worit unit 4:ADO_DEL.2-1 

ISO/IEC 15408-3 AD0_DEL.2.1C: The delivery documentation st)all describe all procedures that are 
necessary to maintain security when distributing versions of the TOE to a user's site. 

The evaluator shall examine the delivery documentation to determine that it describes alt procedures that are 
necessary to maintain security when distributing versions of the TOE or parts of it to the user's site. 

Interpretation of the term "necessary" will need to consider the nature of the TOE and information contained in 
the ST. The level of protection provided should be commensurate with the assumptions, threats, 
organisational security policies, and security objectives identified in the ST. In some cases these may not be 
explicitly expressed in relation to delivery. The evaluator should determine that a balanced approach has been 
taken, such that delivery does not present an obvious weak point in an othenwise secure development process. 

The delivery procedures describe proper procedures to determine the identification of the TOE and to 
maintain security of the TOE during transfer of the TOE or its component parts. The procedures describe 
which parts of the TOE need to be covered by these procedures. It should contain procedures for physical or 
electronic (e.g. for downloading off the Internet) distribution where applicable. The delivery procedures refer to 
the entire TOE, including applicable software, hardware, firmware and documentation. 

The emphasis in the delivery documentation is likely to be on measures related to integrity, as technical 
measures are required to be applied to maintain integrity during the TOE delivery. However, confidentiality 
and availability of the delivery will be of concern in the delivery of some TOEs; procedures relating to these 
aspects of the secure delivery should also be discussed in the procedures. 
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The delivery procedures should be applicable across all phases of delivery from the production environment to 
the installation environment (e.g. packaging, storage and distribution). 

Standard commercial practice for packaging and delivery may be acceptable. This includes shrink wrapped 
packaging, a security tape or a sealed envelope. For the distribution, the public mail or a private distribution 
service may be acceptable. 

The suitability of the choice of the delivery procedures is influenced by the TOE (e.g. w/hether it is software or 
hardware) and by the security objectives. In cases where the delivery procedures differ for different parts of 
the TOE, the totality of procedures are suitable to meet the overall security objectives. 

13.5.1.3.2 Work unit 4:ADO_DEL.2-2 

ISO/IEC 15408-3 AD0_DEL.2.2C: The delivery documentation shall describe how the various procedures and 
technical measures provide for the detection of modifications, or any discrepancy between the developer's 
master copy and the version received at the user site. 

The evaluator shall examine the delivery documentation to determine that it describes how the various 
procedures and technical measures provide for the detection of modifications or any discrepancy between the 
developer's master copy and the version received at the user site. 

Checksum procedures, software signature, or tamper proof seals may be used by the developer to ensure 
that tampering can be detected. The developer may also employ other procedures (e.g. a recorded delivery 
service) that register the name of the originator and supplie the name to the receiver. 

Technical measures for the detection of any discrepancy between the developer's master copy and the 
version received at the user site should be described in the delivery procedures. 

1 3.5.1 .3.3 Work unit 4:ADO_DEL.2-3 

ISO/IEC 15408-3 ADO_DEL.2.3C: The delivery documentation shall describe how the various procedures 
allow detection of attempts to masquerade as the developer, even in cases in which the developer has sent 
nothing to the user's site. 

The evaluator shall examine the delivery documentation to determine that it describes how the various 
mechanisms and procedures allow detection of attempted masquerading even in cases in which the 
developer has sent nothing to the user's site. 

This requirement may be fulfilled by delivering the TOE or parts of it (e.g. by an agent known to and trusted by 
both developer and user). For a software TOE a digital signature may be appropriate. 

If the TOE is delivered by electronic download, the security can be maintained by using digital signatures, 
integrity checksums, or encryption. 

13.5.1.4 Implied evaluator action 

1 3.5.1 .4.1 Work unit 4: ADO_DEL.2-4 

ISO/IEC 15408-3 ADO_DEL.2.2D: The developer shall use the delivery procedures. 

The evaluator shall examine aspects of the delivery process to determine that the delivery procedures are 
used. 

The approach taken by the evaluator to check the application of delivery procedures will depend on the nature 
of the TOE, and the delivery process itself. In addition to examination of the procedures themselves, the 
evaluator should seek some assurance that they are applied in practice. Some possible approaches are: 

a) a visit to the distribution site(s) where practical application of the procedures may be observed; 
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b) examination of tiie TOE at some stage during delivery, or at the user's site (e.g. checl<ing for tamper proof 
seals); 

c) observing that the process is applied in practice when the evaluator obtains the TOE through regular 
channels; 

d) questioning end users as to how the TOE was delivered. 

For guidance on site visits see A.5, Site Visits. 

It may be the case of a newly developed TOE that the delivery procedures have yet to be exercised. In these 
cases, the evaluator has to be satisfied that appropriate procedures and facilities are in place for future 
deliveries and that all personnel involved are aware of their responsibilities. The evaluator may request a "dry 
run" of a delivery if this Is practical. If the developer has produced other similar products, then an examination 
of procedures in their use rtiay be useful in providing assurance. 

13.5.2 Evaluation of Installation, generation and start-up (AD0JGS.1) 

13.5.2.1 Objectives 

The objective of this sub-activity is to determine whether the procedures and steps for the secure installation, 
generation, and start-up of the TOE have been documented and result in a secure configuration. 

13.5.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the administrator guidance; 

b) the secure installation, generation, and start-up procedures; 

c) the TOE suitable for testing. 

13.5.2.3 Application notes 

The installation, generation, and start-up procedures refer to all installation, generation, and start-up 
procedures, regardless of whether they are performed at the user's site or at the development site that are 
necessary to progress the TOE to the secure configuration as described in the ST. 

13.5.2.4 Action ADO JGS.1. IE 

13.5.2.4.1 Work unit 4:AD0_IGS.1-1 

ISO/IEC 15408-3 AD0_IGS.1.1C; The installation, generation and start-up documentation shall describe all 
the steps necessary for secure installation, generation and start-up of the TOE. 

The evaluator shall check that the procedures necessary for the secure installation, generation and start-up of 
the TOE have been provided. 

If it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

13.5.2.5 Action AD0JGS.1.2E 

13.5.2.5.1 Work unit 4:ADO_IGS.1-2 

The evaluator shall examine the provided installation, generation, and start-up procedures to determine that 
they describe the steps necessary for secure installation, generation, and start-up of the TOE. 
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ff it is not anticipated that the installation, generation, and start-up procedures will or can be reapplied (e.g. 
because the TOE may already be delivered in an operational state) this work unit (or the effected parts of it) is 
not applicable, and is therefore considered to be satisfied. 

The installation, generation, and start-up procedures may provide detailed Information about the following: 

a) changing the installation specific security characteristics of entities under the control of the TSF; 

b) handling exceptions and problems; 

c) minimum system requirements for secure installation if applicable. 

tn order to confirm that the installation, generation, and start-up procedures result in a secure configuration, 
the evaluator may follow the developer's procedures and may perform the activities that customers are usually 
expected to perform to install, generate, and start-up the TOE (if applicable to the TOE), using the supplied 
guidance documentation only. This work unit might be performed In conjunction with the ATEJND.1-2 work 

unit. 

13.6 Development activity 

The purpose of the development activity is to assess the design documentation in terms of its adequacy to 
understand how the TSF provides the security functions of the TOE. This understanding is achieved through 
examination of increasingly refined descriptions of the TSF design documentation. Design documentation 
consists of a functional specification (which describes the external interfaces of the TOE), a high-level design 
(which describes the architecture of the TOE in terms of internal subsystems), and a low-level design (which 
describes the architecture of the TOE In terms of internal modules). Additionally, there is an implementation 
description (a source code level description), a security policy model (which describes the security policies 
enforced by the TOE) and a representation correspondence (which maps representations of the TOE to one 
another in order to ensure consistency). 

13.6.1 Application notes 

ISO/IEC 15408 requirements for design documentation are levelled by formality. ISO/IEC 15408 considers a 
document's degree of formality (that is, whether it is informal, semiformal or formal) to be hierarchical. An 
informal document is one that is expressed in a natural language. The methodology does not dictate the 
specific language that must be used; that issue is left for the scheme. The following paragraphs differentiate 
the contents of the different informal documents. 

An informal functional specification comprises a description the security functions (at a level similar to that of 
the TOE summary specification) and a description of the externally-visible interfaces to the TSF. For example, 
if an operating system presents the user with a means of self-identification, of creating files, of modifying or 
deleting files, of setting permissions defining what other users may access files, and of communicating with 
remote machines, its functional specification would contain descriptions of each of these funcfions. If there are 
also audit functions tKat detect and record the occurrences x>f such events, descriptions of these audit 
functions would also be expected to be part of the functional specification; while these functions are 
technically not directly invoked by the user at the external interface, they certainly are affected by what occurs 
at the user's external interface. 

An informal high-level design is expressed in terms of sequences of actions that occur in each subsystem in 
response to stimulus at its interface. For example, a firewall might be composed of subsystems that deal with 
packet filtering, with remote administration, with auditing, and with connection-level filtering. The high-level 
design description of the firewall would describe the actions that are taken, in terms of what actions each 
subsystem takes when an incoming packet arrives at the firewall. 

An informal low-ievel design is expressed in terms of sequences of actions that occur in a module in response 
to stimulus at its interface. For example, a virtual private networking subsystem might be composed of 
modules that create session keys, that encrypt traffic, that decrypt traffic, and that decide whether traffic needs 
to be encrypted. The low-tevel description of the encryption module would describe the steps that the module 
takes when it receives a traffic stream that is to be encrypted. 
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While the functional specification describes the functions and services, the model describes the policies those 
functions and services enforce. An informal model is simply a description of the security policies enforced by 
services or functions available at the external interface. For example, access control policies would describe 
the resources being protected and the conditions that must be met for access to be granted; audit policies 
would describe the TOE's auditable events, identifying both those that are selectable by the administrator and 
those that are always audited; identification and authentication policies would describe how users are 
identified, how those claimed identities are authenticated, and any rules affecting how identities are 
authenticated (e.g. users on the corporate intranet need no authentication, while external users are 
authenticated with one-time passwords). 

Informality of the demonstration of correspondence need not be in a prose form; a simple two-dimensional 
mapping may be sufficient. For example, a matrix with modules listed along one axis and subsystems listed 
along the other, with the cells identifying the correspondence of the two, woUld serve to provide an adequate 
informal correspondence between the high-level design and the low-level design. 

13.6.2 Evaluation of Functional specification (ADV_FSP.2) 

13.6.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has provided an adequate description 
of all security functions of the TOE and whether the security functions provided by the TOE are sufficient to 
satisfy the security functional requirements of the ST. 

13.6.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance. 

13.6.2.3 Action ADV_FSP.2.1E 

13.6.2.3.1 Work unit 4:ADV_FSP.2-1 

ISO/IEC 15408-3 ADV_FSP.2.1C: The functional specincation shall describe ihe TSF and its external 
interfaces using an informal style. 

The evaluator shall examine the functional specification to determine that it contains all necessary informal 
explanatory text. 

If the entire functional specification Is informal, this work unit is not applicable and is therefore considered to 
be satisfied. 

Supporting narrative descriptions are necessary for those portions of the functional specification that are 
difficult to understand only from the semlformal or formal description (for example, to make clear the meaning 
of any formal notation). 

1 3.6.2.3.2 Work unit 4: ADV_FSP.2-2 

ISO/IEC 1 5408-3 ADV_FSP.2.2C: The functional specification shall be internally consistent. 

The evaluator shall examine the functional specification to determine that It is internally consistent. 
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The evaluator validates the functional specification by ensuring that the descriptions of the interfaces making 
up the TSFI are consistent with the descriptions of the functions of the TSF. 

13.6.2.3.3 Work unit 4:ADV_FSP.2-3 

ISO/IEC 15408-3 ADV_FSP.2.3C: The functional speci^cation shall describe the purpose and method of use 
of all external TSF interfaces, providing complete details of all effects, exceptions and error messages. 

The evaluator shall examine the functional specification to determine that it identifies all of the external TOE 
security function interfaces. 

The term external refers to that which is visible to the user. External interfaces to the TOE are either direct 
interfaces to the TSF or interfaces to non-TSF portions of the TOE. However, these non-TSF interfaces might 
have eventual access to the TSF. These external interfaces that directly or indirectly access the TSF 
collectively make up the TOE security function interface (TSFI). Figure 12 shows a TOE with TSF (cross- 
hatched) portions and non-TSF (empty) portions. This TOE has three external interfaces: interface c is a direct 
interface to the TSF; interface b is an indirect interface to the TSF; and interface a is an interface to non-TSF 
portions of the TOE. Therefore, interfaces b and c make up the TFSI. 



J- 

(a) 




TOE 



Figure 12 -TSF Interfaces 

It should be noted that all security functions reflected in the functional requirements of ISO/IEC 15408-2 (or in 
extended components thereof) will have some sort of externally-visible manifestation. While not all of these 
are necessarily interfaces from which the security function can be tested, they are all externally-visible to 
some extent and must therefore be included in the functional specification. 

13.6.2.3.4 Work unit 4:ADV_FSP.2-4 

The evaluator shall examine the functional specification to determine that it describes all of the external TOE 
security function interfaces. 

For a TOE that has no threat of malicious users (i.e. TSF physical protection (FPT_.PHP), Reference 
mediation (FPT_RVM), and Domain separation (FPT_SEP) are rightfully excluded from its ST), the only 
interfaces that are described in the functional specification (and expanded upon in the other TSF 
representation descriptions) are those to and from the TSF. The absence of TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) presumes there is no 
concern for any sort of bypassing of the security features; therefore, there is no concern with any possible 
impact that other interfaces might have on the TSF. 

On the other hand, if the TOE has a threat of malicious users or bypass (i.e. TSF physical protection 
(FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) are included in its ST), ail 
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external interfaces are described in the functional specification, but only to the extent that the effect of each is 
made clear: interfaces to the security functions (i.e. interfaces b and c in Figure 12) are completely described, 
while other interfaces are described only to the extent that it is clear that the TSF Is inaccessible through the 
interface (i.e. that the interface is of type a, rather than b in Figure 12). The inclusion of TSF physical 
protection (FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) implies a 
concern that all interfaces might have some effect upon the TSF. Because each external interface is a 
potential TSF interface, the functional specification must contain a description of each interface in sufficient 
detail so that an evaluator can determine whether the interface is security relevant. 

Some architectures lend themselves to readily provide this interface description in sufficient detail for groups 
of external interfaces. For example, a kernel architecture is such that all calls to the operating system are 
handled by kernel programs; any calls that might violate the TSP must be called by a program with the 
privilege to do so. All programs that execute with privilege must be included in the functional specification. Any 
program external to the kernel that executes without privilege is incapable of affecting the TSP (i.e. such 
programs are interfaces of type a, rather than b in Figure 12) and may, therefore, be excluded from the 
functional specification. It is worth noting that, while the evaluator's understanding of the interface description 
can be expedited in cases where there is a kernel architecture, such an architecture is not necessary. 

1 3.6.2.3.5 Work unit 4:ADV_FSP.2-5 

The evaluator shall examine the presentation of the TSFl to determine that it adequately and correctly 
describes the complete behaviour of the TOE at each external interface describing effects, exceptions and 
error messages. 

In order to assess the adequacy and correctness of an interface's presentation, the evaluator uses the 
functional specification, the TOE summary specification of the ST, and the user and administrator guidance to 
assess the following factors: 

a) All security relevant user input parameters (or a characterisation of those parameters) should be identified. 
For completeness, parameters outside of direct user control should be identified if they are usable by 
administrators. 

b) Complete security relevant behaviour described in the reviewed guidance should be reflected in the 
description of semantics in the functional specification. This should include an identification of the 
behaviour in terms of events and the effect of each event. For example, if an operating system provides a 
rich file system interface, where it provides a different error code for each reason why a file is not opened 
upon request, the functional specification should explain that a file is either opened upon request, or else 
that the request is denied, along with a listing of the reasons why the open request might be denied (e.g. 
access denied, no such file, file is in use by another user, user is not authorised to open the file after 5pm, 
etc.). It would be insufficient for the functional specification merely to explain that a file is either opened 
upon request, or else that an error code is returned. The description of the semantics should include how 
the security requirements apply to the interface (e.g. whether the use of the interface is an auditable 
event and, if so, the information that can be recorded). 

c) All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, 
the description of the interface should explain how the interfece behaves in the presence or absence of 
privilege. 

d) The information contained in the descriptions of the security relevant parameters and syntax of the 
interface should be consistent across all documentation. 

Verification of the above is done by reviewing the functional specification and the TOE summary specification 
of the ST, as well as the user and administrator guidance provided by the developer. For example, if the TOE 
were an operating system and its underlying hardware, the evaluator would look for discussions of user- 
accessible programs, descriptions of protocols used to direct the activities of programs, descriptions of user- 
accessible databases used to direct the activities of programs, and for user interfaces (e.g. commands, 
application program interfaces) as applicable to the TOE under evaluation; the evaluator would also ensure 
that the processor instruction set is described. 
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This review might be iterative, such that the evaluator would not discover the functional specification to be 
incomplete until the design, source code, or other evidence is examined and found to contain parameters or 
error messages that have been omitted from the functional specification. 

13.6.2.3.6 Work unit 4:ADV_FSP.2-6 

ISO/IEC 1 5408-3 ADV_FSP.2.4C: The functional specirication shall completely represent the TSF. 

The evaluator shall examine the functional specification to determine that the TSF is fully represented. 

In order to assess the completeness of the TSF representation, the evaluator consults the TOE summary 
specification of the ST, the user guidance, and the administrator guidance. None of these should describe 
security functions that are absent from the TSF presentation of the functional specification. 

13.6.2.3.7 Work unit 4:ADV_FSP.2-7 

ISO/IEC 15408-3 ADV_FSP.2.5C: The functional specification shall include rationale that the TSF is 
completely represented 

The evaluator shall examine the functional specification to determine that it contains a convincing argument 
that the TSF is completely represented by the functional specification. 

The evaluator determines that there is a convincing argument that there are no interfaces of the TSFI that are 
missing from the functional specification. This may include a description of the procedure or methodology that 
the developer used to ensure that all external interfaces are covered. The argument would prove inadequate if, 
for example, the evaluator discovers commands, parameters, error messages, or other interfaces to the TSF 
in other evaluation evidence, yet absenttrom the functional specification. 

13.6.2.4 Action ADV_FSP.2.2E 

13.6.2.4.1 Work unit 4:ADV_FSP.2-8 

The evaluator shall examine the functional specification to determine that it is a complete instantiation of the 
TOE security functional requirements. 

To ensure that all ST security functional requirements are covered by the functional specification, the 
evaluator may construct a map between the TOE summary specification and the functional specification. Such 
a map might be already provided by the developer as evidence for meeting the correspondence 
(Representation correspondence (ADV_RCR).*) requirements, in which case the evaluator need only verify 
the completeness of this mapping, ensuring that all security functional requirements are mapped onto 
applicable TSFI presentations in the functional specification. 

1 3.6.2.4.2 Work unit 4:ADV_FSP.2-9 

The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the 
TOE security functional requirements. 

For each interface to a security function with specific characteristics, the detailed infomnation in the functional 
specification must be exactly as it is specified in the ST. For example, if the ST contains user authentication 
requirements that the password length must be eight characters, the TOE must have eight-character 
passwords; if the functional specification describes six-character fixed length passwords, the functional 
specification would not be an accurate instantiation of the requirements. 

For each interface in the functional specification that operates on a controlled resource, the evaluator 
determines whether it returns an error code that indicates a possible failure due to enforcement of one of the 
security requirements; if no error code is returned, the evaluator determines whether an error code should be 
returned. For example, an operating system might present an Interface to OPEN a controlled object. The 
description of this Interface may include an error code that indicates that access was not authorised to the 
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object. If such an error code does not exist, the evaluator should confirm that this is appropriate {because, 
perhaps, access mediation is performed on READs and WRITEs, rather than on OPENs). 

13.6.3 Evaluation of High-level design (ADV_HLD.2) 

13.6.3.1 Objectives 

The objective of this sub-activity is to determine whether the high-level design provides a description of the 
TSF in terms of major structural units (i.e. subsystems), provides a description of the interfaces to these 
structural units, and is a correct realisation of the functional specification. 

13.6.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design. 

1 3.6.3.3 Action ADV_HLD.2.1 E 

1 3.6.3.3.1 Work unit 4: ADV_HLD.2-1 

ISO/IEC 15408-3 ADV_HLD.2.1C: The presentation of the high-level design shall be Infomial. 

The evaluator shall examine the high-level design to determine that it contains all necessary informal 
explanatory text. 

If the entire high-level design is informal, this work unit is not applicable and is therefore considered to be 
satisfied. 

Supporting narrative descriptions are necessary for those portions of the high-level design that are difficult to 
understand only from the semiformal or formal description (for example, to make clear the meaning of any 
formal notation). 

13.6.3.3.2 Work unit4:ADV_HLD.2-2 

ISO/IEC 15408-3 ADV_HLD.2.2C: The high-level design shall be internally consistent. 

The evaluator shall examine the presentation of the high-level design to determine that it is internally 
consistent. 

For guidance on consistency analysis see A.3, Consistency analysis. 

The evaluator validates the subsystem interface specifications by ensuring that the interface specificatioris are 
consistent with the description of the purpose of the subsystem. 

13.6.3.3.3 Work unit 4:ADV_HLD.2-3 

ISO/IEC 15408-3 ADV_HLD.2.3C: The high-level design shall describe the structure of the TSF in tenvs of 
subsystems. 

The evaluator shall examine the high-level design to determine that the TSF is described in terms of 
subsystems. 
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With Fespect to the high-level design, the term subsystem refers to large, related units (such as memory- 
management, file-management, process-management). Breaking a design into the basic functional areas aids 
in the understanding of the design. 

The primary purpose for examining the high-level design is to aid the evaluator's understanding of the TOE. 
The developer's choice of subsystem definition, and of the grouping of TSFs within each subsystem, are an 
important aspect of making the high-level design useful in understanding the TOE's intended operation. As 
part of this work unit, the evaluator should make an assessment as to the appropriateness of the number of 
subsystems presented by the developer, and also of the choice of grouping of functions within subsystems. 
The evaluator should ensure that the decomposition of the TSF into subsystems is sufficient for the evaluator 
to gain a high-level understanding of how the functionality of the TSF is provided. 

The subsystems used to describe the high-level design need not be called "subsystems", but should represent 
a similar level of decomposition. For example, the design may be decomposed using "layers" or "managers". 

There may be some interaction between the choice of subsystem definition and the scope of the evaluator's 
analysis. A discussion on this interaction is found following work unit ADV_HLD.2-10. 

1 3.6.3.3.4 Work unit 4:ADV_HLD.2-4 

ISO/IEC 15408-3 ADV_HLD.2.4C: The high-level design shall descn'be the security functionality provided by 
each subsystem of the TSF. 

The evaluator shall examine the high-level design to determine that it describes the security functionality of 
each subsystem. 

The security functional behaviour of a subsystem is a description of what the subsystem does. This should 
include a description of any actions that the subsystem may be directed to perform through its functions and 
the effects the subsystem may have on the security state of the TOE (e.g. changes in subjects, objects, 
security databases). 

13.6.3.3.5 Work unit 4:ADV_HLD.2-5 

(SO/IEC 15408-3 ADV_HLD.2.5C: The high-level design shall identify any underlying hardware, firmware, 
and/or software required by the TSF with a presentation of the functions provided by the supporting protection 
mechanisms implemented in that hardware, firmware, or software. 

The evaluator shall check the high-level design to determine that it identifies all hardware, firmware, and 
software required by the TSF. 

If the ST contains no security requirements for the IT environment, this work unit is not applicable and is 
therefore considered to be satisfied. 

If the ST contains the optional statement of security requirements for the IT environment, the evaluator 
compares the list of hardware, firmware, or software required by the TSF as stated in the high-level design to 
the statement of security requirements for the IT environment to determine that they agree. The information in 
the ST characterises the underlying abstract machine on which the TOE will execute. 

If the high-level design includes security requirements for the IT environment that are not included in the ST, 
or if they differ from those included in the ST, this inconsistency is assessed by the evaluator under Action 
ADV_HLD.2.2E. 

1 3.6.3.3.6 Work unit 4:ADV_HLD.2-6 

The evaluator shall examine the high-level design to determine that it includes a presentation of the functions 
provided t)y the supporting protection mechanisms implemented in the underlying hardware, firmware, or 
software. 
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tf the ST contains no security requirements for the IT environment, this work unit is not applicable and is 
therefore considered to be satisfied. 

The presentation of the functions provided by the underlying abstract machine on which the TOE executes 
need not be at the same level of detail as the presentation of functions that are part of the TSF. The 
presentation should explain how the TOE uses the functions provided in the hardware, firmware, or software 
that implement the security requirements for the IT environment that the TOE is dependent upon to support 
the TOE security objectives. 

The statement of security requirements for the IT environment may be abstract, particularly if it is intended to 
be capable of being satisfied by a variety of different combinations of hardware, firmware, or software. As part 
of the Tests activity, where the evaluator Is provided with at least one instance of an underlying machine that 
is claimed to satisfy the security requirements for the IT environment, the evaluator can determine whether it 
provides the necessary security functions for the TOE. this determination by the evaluator does not require 
testing or analysis of the underlying machine; it Is only a determination that the functions expected to be 
provided by it actually exist. 

13.6.3.3.7 Work unit 4:ADV_HLD.2-7 

ISO/IEC 15408-3 ADV_HLD.2.6C: The high-level design shall identify all interfaces tathe subsystems of the 
TSF. 

The evaluator shall check that the high-level design identifies.the interfaces to the TSF subsystems. 

The high-level design includes, for each subsystem, the name of each of its entry points. 

13.6.3.3.8 Work unit 4:ADV_HLD.2-8 

ISO/iEC 15408-3 ADV_HLD.2.7C: The high-level design shall identify which of the interfaces to the 
subsystems of the TSF are externally visible. 

The evaluator shall check that the high-level design identifies which of the interfaces to the subsystems of the 
TSF are externally visible. 

As discussed under work unit ADV_FSP.1-3, external interfaces (i.e. those visible to the user) may directly or 
indirectly access the TSF. Any external interface that accesses the TSF either directly or indirectly is included 
in the identification for this work unit. External interfaces that do not access the TSF need not be included. 

13.6.3.3.9 Work unit 4:ADV_HLD.2-9 

ISO/IEC 15408-3 ADV_HLD.2.8C: The high-level design shall describe the purpose and method of use of all 
interfaces to the subsystems of the TSF, providing details of effects, exceptions and error messages, as 
appropriate. 

The evaluator shall examine the high-level design to determine that it describes the interfaces to each 
subsystem in terms of their purpose and method of use, and provides details of effects, exceptions and error 
messages, as appropriate. 

The high-level design should include descriptions in terms of the purpose and method of use for all interfaces 
of each subsystem. Such descriptions may be provided in general terms for some interfaces, and in more 
detail for others. In determining the level of detail of effects, exceptions and error messages that should be 
provided, the evaluator should consider the purposes of this analysis and the uses made of the interface by 
the TOE. For example, the evaluator needs to understand the nature of the interactions between subsystems 
to establish confidence that the TOE design is sound, and may be able to obtain this understanding with only 
a general description of some of the interfaces between subsystems. In particular, internal subsystem entry 
points that are not called by any other subsystem would not normally require detailed descriptiorrs. 
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The level of detail may also depend on the testing approach adopted to meet the Depth (ATE_DPT) 
requirement. For example, a different amount of detail may be needed for a testing approach that tests only 
through external interfaces than one that tests through both external and internal subsystem interfaces. 

Detailed descriptions would include details of any input and output parameters, of the effects of the interface, 
and of any exceptions or error messages it produces. In the case of external interfaces, the required 
description is probably included in the functional specification and can be referenced in the high-level design 
without replication. 

13.6.3.3.10 Work unit4:ADV_HLD.2-10 

ISO/IEC 15408-3 ADV_HLD.2.9C: The high-level design shall describe the separation of the TOE into TSP- 
enf arcing and other subsystems. 

The evaluator shall check that the high-level design describes the separation of the TOE into TSP-enforcing 
and other subsystems. 

The TSF comprises all the parts of the TOE that have to be relied upon for enforcement of the TSP. Because 
the TSF includes both functions that directly enforce the TSP, and also those functions that, while not directly 
enforcing the TSP, contribute to the enforcement of the TSP in a more indirect manner, all TSP-enforcing 
subsystems are contained in the TSF. Subsystems that play no role in TSP enforcement are not part of the 
TSF. An entire subsystem is part of the TSF if any portion of it is. 

As explained under work unit ADV_HLD.2-3, the developer's choice of subsystem definition, and of the 
grouping of TSFs within each subsystem, are important aspects of making the high-level design useful in 
understanding the TOE's intended operation. However, the choice of grouping of TSFs within subsystems 
also affects the scope of the TSF, because a subsystem with any function that directly or indirectly enforces 
the TSP is part of the TSF. While the goal of understandability is important, it is also helpful to limit the extent 
of the TSF so as to reduce the amount of analysis that is required. The two goals of understandability and 
scope reduction may sometimes work against each other. The evaluator should bear this in mind when 
assessing the choice of subsystem definition. 

13.6.3.4 Action ADV_HLD.2.2E 

1 3.6.3.4.1 Work unit 4:ADV_HLD.2-1 1 

The evaluator shall examine the high-level design to determine that it is an accurate instantiation of the TOE 
security functional requirements. 

The evaluator analyses the high-level design for each TOE security function to ensure that the function is 
accurately described. The evaluator also ensures that the function has no dependencies that are not included 
in the high-level design. 

The evaluator also analyses the security requirements for the IT environment in both the ST and the high-level 
design to ensure that they agree. For example, if the ST includes TOE security functional requirements for the 
storage of an audit trail, and the high-level design stated that audit trail storage is provided by the IT 
environment, then the high-level design is not an accurate instantiation of the TOE security functional 
requirements. 

The evaluator should validate the subsystem interface specifications by ensuring that the interface 
specifications are consistent with the description of the purpose of the subsystem. 

13.6.3.4.2 Work unit 4:ADV_HLD.2-12 

The evaluator shall examine the high-level design to determine that it is a complete instantiation of the TOE 
security functional requirements. 

To ensure that all ST security functional requirements are covered by the high-level design, the evaluator may 
construct a map between the TOE security functional requirements and the high-level design. 
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13.6.4 Evaluation of Implementation representation (ADVJMP.I) 

13.6.4.1 Objectives 

The objective of this sub-activity is to determine whether the implementation representation is sufficient to 
satisfy the functional requirements of the ST and is a correct realisation of the low-level design. 

13.6.4.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the low-level design; 

c) the subset of the implementation representation. 

13.6.4.3 Action ADVJMP.1. IE 

13.6.4.3.1 Work unit 4:ADV_IMP.1-1 

ISO/IEC 15408-3 ADV_IMP.1.1C: The implementation representation sliall unambiguously define the TSF to 
a level of detail such that the TSF can be generated without further design decisions. 

The evaluator shall examine the implementation representation to determine that it unambiguously defines the 
TSF to a level of detail such that the TSF can be generated without any further design decisions. 

This work unit requires the evaluator to confirm that the implementation representation is suitable for analysis. 
The evaluator should consider the process needed to generate the TSF from the representation provided. If 
the process is welt-defined, requiring no further design decisions (for example, requiring only the compilation 
of source code, or the building of hardware from hardware drawings), then the implementation representation 
can be said to be suitable. 

Any programming languages used must be well defined with an unambiguous definition of all statements, as 
well as the compiler options used to generate the object code. This determination will have been made as part 
of the ALC_TAT.1 Well-defined development tools sub-activity. 

13.6.4.3.2 Worl<unit4:ADVJIV!P.1-2 

The evaluator shall examine the implementation representation provided by the developer to determine that it 
is sufficiently representative. 

The developer is required to provide the implementation representation for only a subset of the TSF. If the PP 
or ST specifies a selected subset, then the specified subset is also required of the developer. The developer 
can select and offer an initial subset, but the evaluator may require additional portions, or even different 
subsets. 

The evaluator determines the adequacy and appropriateness of the subset by applying the principles of 
sampling. 

For guidance on sampling see A.2, Sampling. 

In determining the appropriateness of the subset, the evaluator decides if it is suitable for use in aiding the 
evaluator to understand and gain assurance of the correctness of the implementation of the TSF mechanisms. 
In making this determination, the evaluator should consider the different methods of representation used by 
the developer, so that the evaluator is satisfied that a representative subset has been selected. 

For example, for a TOE that is realised in the manner of a conventional operating system, the selected subset 
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such as command or application programs. If some of the source code is known to have originated from 
different development organisations, the selected subset should contain samples from each of the different 
creating organisations. If the implementation representation source code includes different forms of 
programming languages, the subset should contain samples of each differfent language. 

In the case that the implementation representation includes hardware drawings, several different portions of 
the TOE should be included in the subset. For example, for a TOE including a desktop computer, the selected 
subset should contain samples for peripheral controllers as well as the main computer board. 

Other factors that might influence the determination of the subset include: 

a) the complexity of the design (if the design complexity varies across the TOE, the subset should include 
some portions with high complexity); 

b) scheme requirements; 

c) the results of other design analysis sub-activities (such as work units related to the low-level or high-level 
design) that might indicate portions of the TOE in which there is a potential for ambiguity in the design; 
and 

d) the evaluator's judgement as to portions of the implementation representation that might be useful forihe 
evaluator's independent vulnerability analysis (sub-activity AVA_\/LA.2 Independent vulnerability 
analysis). 

1 3.6.4.3.3 Work unit 4: ADVJMP.1 -3 

ISO/IEC 15408-3 ADVJMP.1. 20: The implementation representation shall be internally consistent. 

The evaluator shall examine the implementation representation to determine that it is internally consistent. 

Because the developer is required to provide only a subset of the implementation representation, this work 
unit calls on the evaluator to make a determination of consistency jonly for the subset provided. The evaluator 
looks for inconsistencies by comparing portions of the implementation representation. In the case of source 
code, for example, if one portion of the source code includes a call to a subprogram in another portion, the 
evaluator looks to see that the arguments of the calling program match the called program's handling of the 
arguments. In the case of hardware drawings, the evaluator looks for such things as agreement between the 
nature and characteristics of the two ends of a circuit trace (e.g. voltage level, direction of logic, signal timing 
requirements). For guidance on consistency analysis see A.3, Consistency analysis. 

1 3.6.4.4 Action ADVJMP.1 .2E 

1 3.6.4.4.1 Work unit 4: ADVJMP.1 -4 

The evaluator shall examine the implementation representation subset to determine that it accurately 
instantiates those TOE security functional requirements relevant to the subset. 

For those portions of the implementation representation subset that provide security functions directly, the 
evaluator determines that the implementation matches the TOE security functional requirement. The 
remaining portions of the implementation representation subset may support some TOE functional 
requirement. In making a determination about these remaining portions, the evaluator makes use of the low- 
level design to assess if the portions in the implementation representation subset, in combination with other 
portions as described in the low-level design, work together to instantiate a TOE security functional 
requirement. 

The remaining portions of the implementation representation subset, if any, can generally be ignored because 
they are unrelated to any of the TOE security functional requirements supported by the implementation subset. 
However, the evaluator should be careful to not overlook any portions that play an indirect role, no matter how 
distant, in supporting the TOE security functions. For example, In typical operating systems, the source code 
for portions of the nucleus (or kernel) may not have any direct role in supporting a TOE security function, but 
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are capable of interfering with the correct functioning of those portions of the nucleus that do have a direct role. 
If any such portions are found to exist in the subset of the implementation representation provided, they 
should be assessed not to interfere with the portions that do, provided that the ST requires such non- 
interference. This assessment typically will not require the same level of detailed examination that is required 
for those portions of the implementation representation that play a more direct role in supporting the TOE 
security functions. 

13.6.5 Evaluation of Low-level design (ADV_LLD.1) 

13.6.5.1 Objectives 

The objective of this sub-activity is to determine whether the low-level design is sufficient to satisfy the 
functional requirements of the ST, and is a correct and effective refinement of the high-level design. 

13.6.5.2 input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the low-level design. 

1 3.6.5.3 Action ADV_LLD.1 .1 E 

13.6.5.3.1 Work unit 4:ADV_LLD.1-1 

iSO/lEC 15408-3 ADV_LLD.1 .1C: The presentation of the low-level design shall be informal. 

The evaluator shaft examine the low-level design to determine that it contains all necessary informal 
explanatory text. 

If the entire low-level design is informal, this work unit is not applicable and is therefore considered to be 
satisfied. 

Supporting narrative descriptions are necessary for those portions of the low-level design that are difficult to 
understand only from the semiformal or formal description (for example, to make clear the meaning of any 
formal notation). 

13.6.5.3.2 Workunit4:ADV_LLD.1-2 

ISO/lEC 1 5408-3 ADV_LLD.1 .20: The low-level design shall be internally consistent. 

The evaluator shall examine the presentation of the low-level design to determine that it is internally consistent. 

For guidance on consistency analysis see A.3, Consistency analysis. 

13.6.5.3.3 Work unit 4:AOV_LLD.1-3 

ISO/lEC 15408-3 ADV_LLD.1 .30: The low-level design shall describe the TSF in terms of modules. 

The evaluator shall check the low-level design to determine that it describes the TSF in terms of modules. 

The term module is used in this family by ISO/lEC 15408 to denote a less abstract entity than a subsystem. 
This means that it contains more detail as to, not only the module's purpose, but also the manner in which the 
module achieves its purpose. Ideally, the low-level design would provide all the information needed to 
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implement the modules described in it. The later work units in this sub-activity call for specific analysis to 
determine that a sufficient level of detail is included. For this work unit, it is sufficient for the evaluator to verify 
that each module is clearly and unambiguously identified. 

13.6.5.3.4 Workunlt4:ADV_LLD.1-4 

ISO/lEC 1 5408-3 ADV_LLD. 1 .4C: The low-level design shall describe the purpose of each module. 

The evaluator shall examine the low-level design to determine that it describes the purpose of each moduie. 

The low-level design contains a description of the purpose of each of its modules. These descriptions should 
be clear enough to convey what functions the module is expected to perform. The description should provide 
an overview of a module's purpose and is not intended to be at the level of detail of module interface 
specifications. 

13.6.5.3.5 Work unit 4:ADV_LLD.1-5 

ISO/lEC 15408-3 ADV_LLD.1.5C: The low-level design shall define the interrelationships between the 
modules in terms of provided security functionality and dependencies on other modules. 

The evaluator shall examine the low-level design to determine that it defines the interrelationships between 
the modules in terms of provided security functionality and dependencies on other modules. 

For the purpose of this analysis, modules are viewed as interacting in two ways: 

a) to provide services to one another, and 

b) to cooperate in support of security functions. 

The low-level design should include specific information on these inten'elationships. For example, if a module 
performs calculations that depend on the results of calculations in other modules, those other modules should 
be listed. Further, if a module provides a service intended for other modules to use in supporting security 
functions, the service should be described. It is possible that the description of the purpose of a module, as 
analysed in the preceding work unit, is sufficient to provide this information. 

13.6.5.3.6 Work unit 4:ADV_LLD.1-6 

ISO/lEC 15408-3 ADV_LLD.1.6C: The low-level design shall describe how each TSP-enforcIng function is 
provided. 

The evaluator shall examine the low-level design to determine that it describes how each of the TSP-enforcing 
functions is provided. 

The TSP-enforcing functions are those functions of the TSF that directly or indirectly enforce the TSP. 

It is this description in the iow-level design that is key to the assessment as to whether the low-level design is 
sufficiently refined to permit an implementation to be created. The evaluator should analyse the description 
from the point of view of an implementor. If the evaluator, using the impfementor's viewpoint, is unclear on any 
aspect of how the module could be implemented, the description is incomplete. Note that there is no 
requirement that a module be implemented as a separate unit (be it a program, a subprogram, or a hardware 
component); but the low-level design may be sufficiently detailed to permit such an implementation. 

13.6.5.3.7 Work unit 4:ADV_LLD.1-7 

ISO/lEC 1 5408-3 ADV_LLD. 1 .7C; The low-level design shall identify all interfaces to the modules of the TSF. 
The evaluator shall check that the low-level design identifies the interfaces to the TSF modules. 
The low-level design should include, for each module, the name of each of its entry points. 
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13.6.5.3.8 Work unit4:ADV_LLD.1-8 

ISO/lEC 1 5408-3 ADV_LLD.1 .8C: The low-level design shall identify which of the interfaces to the modules of 
the TSF are externally visible. 

The evaluator shall check that the low-level design identifies which of the interfaces to the modules of the TSF 
are externally visible. 

As discussed under work unit ADV_FSP.2-3, external interfaces (i.e. those visible to the user) may directly or 
indirectly access the TSF. Any external interface that accesses the TSF either directly or indirectly is included 
in the identification for this work unit. External interfaces that do not access the TSF need not be included. 

13.6.5.3.9 Work unit 4:ADV_LLD.1-9 

ISO/lEC 15408-3 ADV_LLD.1.9C: The low-level design shall describe the purpose and method of use of all 
interfaces to the modules of the TSF, providing details of effects, exceptions and envr messages, as 
appropriate. 

The evaluator shall examine the low-level design to determine that it describes the interfaces to each module 
in terms of their purpose and method of use, and provides details of effects, exceptions and error messages, 
as appropriate. 

The module interface descriptions may be provided in general terms for some interfaces, and in more detail 
for others. In determining the necessary level of detail of effects, exceptions and error messages, the 
evaluator should consider the purposes of this analysis and the uses made of the interface by the TOE. For 
example, the evaluator needs to understand the general nature of the interactions between modules to 
establish confidence that the TOE design is sound, and may be able to obtain this understanding with only a 
general description of some of the interfaces between modules. In particular, internal entry points that are not 
called by any other module would not normally require detailed descriptions. 

This work unit may be performed in conjunction with the evaluator's independent vulnerability analysis, which 
is part of the Vulnerability analysis (AVA_VLA) sub-activity. 

Detailed deschptions would include details of any input and output parameters, of the effects of the interface, 
and of any exceptions or error messages it produces. In the case of external interfaces, the required 
description is probably included in the functional specification and can be referenced in the low-level design 
without replication. 

13.6.5.3.10 Work unit 4:ADV_LLD.1 -10 

ISO/lEC 15408-3 ADV_LLD.1.10C: The low-level design shall describe the separation of the TOE into TSP- 
enforcing and other modules. 

The evaluator shall check that the low-level design describes the separation of the TOE into TSP-enforcing 
and other modules. 

The TSF comprises all the parts of the TOE that have to be relied upon for enforcement of the TSP. Because 
the TSF includes both functions that directly enforce the TSP, and also those functions that, white not directly 
enforcing the TSP, contribute to the enforcement of the TSP in a more indirect manner, all TSP-enforcing 
modules are contained in the TSF. Modules that cannot affect TSP enforcement are not part of the TSF. 

13.6.5.4 Action ADV_LLD.1.2E 

13.6.5.4.1 Work unit4:ADV_LLD.1-11 

The evaluator shall examine the low-level design to determine that it is an accurate instantiation of the TOE 
security functional requirements. 
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The evaluator validates the module interface specifications by ensuring that: 

a) the interface specifications are consistent with the description of the purpose of the module; 

b) the interface specifications are consistent with their use by other modules; 

c) the interrelationships between modules that are needed in order that each TSP-enforcing function is 
correctly supported are correctly stated. 

13.6.5.4.2 Work unit 4:ADV_LLD.1-12 

The evaluator shall examine the low-level design to determine that it is a complete instantiation of the TOE 
security functional requirements. 

The evaluator ensures that alt ST functional requirements are mapped onto applicable subclauses of the 
low level design. This determination should be made in conjunction with the ADV_RCR.1 Informal 
correspondence demonstration sub-activity. 

The evaluator analyses the low-level design to determine that each TOE security function is completely 
described by the module specifications, and that there are no modules on which a TOE security function relies 
for which there is no specification in the low-level design. 

13.6.6 Evaluation of Representation correspondence (ADV_RCR.1) 

13.6.6.1 Objectives 

The objective of this sub-activity is to determine whether the developer has correctly and completely 
implemented the requirements of the ST, functional specification, high-level design and low-level design in Vhe 
implementation representation. 

13.6.6.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the low-level design; 

e) a subset of the implementation representation; 

f) the correspondence analysis between the TOE summary specification and the functional specification; 

g) the correspondence analysis between the functional specification and the high-level design; 

h) the correspondence analysis between the high-level design and the low-level design; 

i) the correspondence analysis between the low-level design and the subset of the implementation 
representation. 

13.6.6.3 Action ADV_RCR.1. IE 

i3.6.6.3.1 Worlt unit4:ADV_RCR.1-1 

ISO/IEC 15408-3 ADV_RCR.1.1C: For each adjacent pair of provided TSF representations, ttie analysis shall 
demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and 
completely refined in the less abstract TSF representation. 
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The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV__FSP.1-7 and ADV_FSP.1-8. 

13.6.6.3.2 Work unit 4:ADV_RCR.1-2 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and A0V_FSP.1-8. 

13.6.6.3.3 Workumt4:ADV_RCR.1-3 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specificatton is a correct and complete representation 
of the TOE security functions. 

The evaluator's goal in this work unit is to determine that all security functions identifred in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.1-7 and ADV_FSP.1-8. 

1 3.6.6.3.4 Work unit 4: ADV_RCR.1 -4 

The evaluator shall examine the correspondence analysis between the TOE summary specification and the 
functional specification to determine that the functional specification is a correct and complete representation 
of the TOE security functions. 
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The evaluator's goal in this work unit is to determine that all security functions identified in the TOE summary 
specification are represented in the functional specification and that they are represented accurately. 

The evaluator reviews the correspondence between the TOE security functions of the TOE summary 
specification and the functional specification. The evaluator looks for consistency and accuracy in the 
correspondence. Where the correspondence analysis indicates a relationship between a security function of 
the TOE summary specification and an interface description in the functional specification, the evaluator 
verifies that the security functionality of both are the same. If the security functions of the TOE summary 
specification are correctly and completely present in the corresponding interface, this work unit will be satisfied. 

This work unit may be done in conjunction with work units ADV_FSP.2-8 and ADV_FSP.2-9. 

13.6.6.3.5 Work unit4:ADV_RCR.1-5 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

1 3.6.6.3.6 Work unit 4:ADV_RCR.1 -6 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

13.6.6.3.7 Workunit4:ADV_RCR.1-7 

The evaluator shall examine the correspondence analysis between the functional specification and the high- 
level design to determine that the high-level design is a correct and complete representation of the functional 
specification. 

The evaluator uses the correspondence analysis, the functional specification, and the high-level design to 
ensure that it is possible to map each security function identified in the functional specification onto a TSF 
subsystem described in the high-level design. For each security function, the correspondence indicates which 
TSF subsystems are involved in the support of the function. The evaluator verifies that the high-level design 
includes a description of a correct realisation of each security function. 

13.6.6.3.8 Work unit 4:ADV_RCR.1-8 

The evaluator shall examine the correspondence analysis between the high-level design and the low-level 
design to determine that the low-level design is a correct and complete representation of the high-level design. 

The evaluator uses the correspondence analysis, the high-level design, and the low-levet design to ensure 
that it is possible to map each TSF module identified in the low-level design onto a TSF subsystem described 
in the high-level design. For each TOE security function, the correspondence indicates which TSF modules 
are involved in the support of the function. The evaluator verifies that the low-level design includes a 
description of a correct realisation of each security function. 
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13.6.6.3.9 Work unit 4: ADV RCR.1-9 



The evaluator shall examine the correspondence analysis between the low-level design and the subset of the 
implementation representation to determine that the subset is a correct and complete representation of those 
portions of the low-leve! design that are refined in the implementation representation. 

Since the evaluator examines only a subset of the implementation representation, this work unit is performed 
by assessing the correspondence analysis of the subset of the implementation representation to the relevant 
parts of the low-level design rather than attempting to trace each TOE security function into the 
implementation representation. The subset may provide no coverage for some functions. 

13.6.7 Evaluation of Security policy modeling (ADV_SPIVI.1) 

13.6.7.1 Objectives 

The objectives X)f this sub-activity are to determine whether the security policy model clearly and consistently 
describes the rules and characteristics of the security policies and whether this description corresponds with 
the description of security functions in the functional specification. 

13.6.7.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the TOE security policy model; 

d) the user guidance; 

e) the administrator guidance. 

1 3.6.7.3 Action ADV_SPIVI.1 .1 E 

13.6.7.3.1 Work unit 4:ADV_SPIVI.1-1 

ISO/IEC 15408-3 ADV_SPM.1.1C: The TSP model shall be informal. 

The evaluator shall examine the security policy model to determine that it contains all necessary informal 
explanatory text. 

If the entire model is informal, this work unit is not applicable and is therefore considered to be satisfied. 

Supporting narrative descriptions are necessary for those portions of the model that are difficult to understand 
only from the semiformal or formal description (for example, to make clear the meaning of any formal notation). 

13.6.7.3.2 Workunit4:ADV_SPIV!.1-2 

ISO/IEC 1 5408-3 ADV_SPM.1 .2C: The TSP model shall describe the rules and characteristics of all policies 
of the TSP that can be modeled. 

The evaluator shall check the model to determine that all security policies that are explicitly included in the ST 
are modeled. 

The security policy is expressed by the collection of the functional security requirements in the ST. Therefore, 
to determine the nature of the security policy (and hence what policies must be modeled), the evaluator 
analyses the ST functional requirements for those policies explicitly called for (by Access control policy 
(FDP_ACC) and Information flow control policy (FDPJFC), if included in the ST). 
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Depending upon the TOE, formal/semiformal modeling might not even be possible for access control. (For 
example, the access control policy for a firewall connected to the internet cannot be formally modeled in a 
useful manner because the state of the internet cannot be completely defined.). For any security policy where 
formal or semiformal models are not possible, the policy must be provided in an informal form. 

If the ST contains no explicit policies (because neither Access control policy (FDP_ACC) nor Information flow 
control policy (FDPJFC) are included in the ST), this work unit is not applicable and is therefore considered to 
be satisfied. 

1 3.6.7.3.3 Work unit 4:ADV_SPM.1 -3 

The evaluator shall examine the model to determine that all security policies represented by the security 
functional requirements claimed in the ST are modeled. 

In addition to the explicitly-listed policies (see work unit ADV_SPM.1-2), the evaluator analyses the ST 
functional requirements for those policies implied by the other functional security requirement classes. For 
example, inclusion of FDP: User data protection requirements (other than Access control policy (FDP_ACC) 
and Information flow control policy (FDP_IFC)) would need a description of the Data Protection policy being 
enforced; inclusion of any FIA: Identification and authentication requirements would necessitate that a 
description of the Identification and Authentication policies be present in the model; inclusion of FAU: Security 
audit requirements need a description of the Audit policies; etc. While the other functional requirement families 
are not typically associated with what are commonly referred to as security policies, they nevertheless do 
enforce security policies (e.g. non-repudiation, reference mediation, privacy, etc.) that must be included in the 
security policy model. 

In cases where the model presentation is informal, all security policies can be modeled (i.e. described), and so 
must be included. For any security policy where formal or semiformal models are not possible, the policy must 
be provided in an informal form. 

If the ST contains no such implicit policies, this work unit is not applicable and is therefore considered to be 
satisfied. 

1 3.6.7.3.4 Work unit 4:ADV_SPM.1 -4 

The evaluator shall examine the rules and characteristics of the model to determine that the modeled security 
behaviour of the TOE is clearly articulated. 

The rules and characteristics describe the security posture of the TOE. It is likely that such a description would 
be contained within an evaluated and certified ST. In order to be considered a clear articulation, such a 
description should define the notion of security for the TOE, identify the security attributes of the entities 
controlled by the TOE and identify the TOE actions which change those attributes. For example, if a policy 
attempts to address data integrity concerns, the policy model would: 

a) define the nofion of integrity for that TOE; 

b) identify the types of data for which the TOE would maintain integrity; 

c) identify the entities that could modify that data; 

d) identify the rules that potential modifiers must follow to modify data. 

13.6.7.3.5 Workunlt4:ADV_SPIVI.1-5 

ISO/IEC 15408-3 ADV_SPM.1.3C: The TSP model shall Include a rationale that demonstrates that it is 
consistent and complete with respect to all policies of the TSP that can be modeled. 

The evaluator shall examine the model rationale to determine that the behaviour modeled is consistent with 
respect to policies described by the security polices (as articulated by the functional requirements in the ST). 



204 



IS 15671 :2006 
ISO/IEC 18045: 2005 

In determining consistency, the evaluator verifies that the rationale shows that each rule or characteristic 
description in the model accurately reflects the intent of the security policies. For example, if a policy stated 
that access control was necessary to the granularity of a single individual, then a model describing the 
security behaviour of a TOE in the context of controlling groups of users would not be consistent. Likewise, if 
the policy stated that access control for groups of users was necessary, then a model describing the security 
behaviour of a TOE in the context of controlling individual users would also not be consistent. 

Assurance is to be gained from an explicit and general statement of the policies underlying the TOE security 
functional requirements. The assurance gained is two-fold: collecting the description of each security policy 
into a concise whole aids in understanding the details of the policies being enforced. Additionally, such a 
collected description makes it much easier to see any gaps or inconsistencies (which must be sought as part 
of the Security policy modeling (ADV_SPM).*.3C element), and provides a clear characterisation of secure 
states (sought as part of the Security policy modeling (ADV_SPM).*.2C element). 

The requirement for an Informal Security Policy Model (ISPM) is met by a clear statement of the security 
policy. The need for a separate ISPM is not absolute, since for very straightforward policies, or those very 
clearly expressed in the ST, there may be no need for a separate ISPM. In such cases, different subclauses of 
the ST (e.g. security requirements, TOE summary specification) may combine together to provide a sufficient 
level of detail for the security policy. However, this is often not the case. For example, audit requirements may 
be spread throughout the statement of TOE security functional requirements, which may not provide a clear 
model of the overall policy. Unless another subclause of the ST (perhaps the TOE summary specification) 
pulls together the audit requirements into a cohesive whole, then having a separate ISPM would be necessary 
in order to allow for the detection of inconsistencies within the ST requirements that may othenwise pass 
undetected. 

Where a developer claims that the ISPM requirements for some or all of the security policies are met by the 
ST, the evaluator needs to determine that this is the case by applying the requirements of the ADV_SPM.1 
Informal TOE security policy model component: determining that the policy is clearly expressed, and that the 
model is consistent with the remainder of the ST. As part of the ISPM rationale, it is likely that, in cases where 
the developer claims that the ISPM is met entirely by the ST, that the rationale will reference the 
demonstrations of suitability and correspondence between portions of the ST. When evaluating this work-unit, 
the evaluator may draw upon the results of the ST evaluation in this area. 

For guidance on consistency analysis see A. 3, Consistency analysis, 

13.6.7.3.6 Workunit4;ADV_SPM.1-6 

The evaluator shall examine the model rationale to determine that the behaviour modeled is complete with 
respect to the policies described by the security policies (i.e. as articulated by the functional requirements in 
the ST). 

In determining completeness of this rationale, the evaluator considers the rules and characteristics of the 
model and map those rules and characteristics to explicit policy statements (i.e. functional requirements). The 
rationale should show that all policies that are required to be modeled have an associated rule or 
characteristic description in the model. 

Where a developer claims that the ISPM requirements for some or all of the security policies are met by the 
ST, the evaluator needs to determine that this is the case by applying the requirements of the ADV_SPM.1 
informal TOE security policy model component: determining that the policy is clearly expressed, and that the 
model is complete with respect to the remainder of the ST. When evaluating this work-unit, the evaluator may 
draw upon the results of the evaluation of the completeness of the various portions of the ST. 

13.6.7.3.7 Workunit4:ADV_SPM.1-7 

ISO/lEC 15408-3 ADV_SPM.1.4C: The demonstration of correspondence between the TSP model and the 
functional specification shall show that all of the security functions in the functional specifrcation are consistent 
and complete with respect to the TSP model. 
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The evaluator shall examine the functional specification correspondence demonstration of the policy model to 
determine that it identifies all security functions described in the functional specification that implement a 
portion of the policy. 

in determining completeness, the evaluator reviews the functional specification, identifies which functions 
directly support the model and verifies that these functions are present in the functional specification 
correspondence demonstration of the model. 

13.6.7.3.8 Work unit 4:ADV_SPM.1-8 

The evaluator shall examine the functional specification correspondence demonstration of the model to 
determine that the descriptions of the functions identified as implementing the model are consistent with the 
descriptions in the functional specification. 

To demonstrate consistency, the evaluator verifies that the functional specification correspondence shows that 
the functional description in the functional specification of the functions identified as implementing the policy 
described in the model identify the same attributes and characteristics of the model and enforce the same 
rules as the model. 

In cases where a security policy is enforced differently for untrusted users and administrators, the policies for 
each are described consistently with the respective behaviour descriptions in the user and administrator 
guidance. For example, the "identification and authentication" policy enforced upon remote untrusted users 
might be more stringent than that enforced upon administrators whose only point of access is within a 
physically-protected area; the differences in authentication should correspond to the differences in the 
descriptions of authentication within the user and administrator guidance. 

For guidance on consistency analysts see A.3, Consistency analysis. 

13.7 Guidance documents activity 

The purpose of the guidance document activity is to judge the adequacy of the documentation describing how 
to use the operational TOE. Such documentation includes both that aimed at trusted administrators and non- 
administrator users whose incorrect actions could adversely affect the security of the TOE, as well as that 
aimed at untrusted users whose incorrect actions could adversely affect the security of their own data. 

13.7.1 Application notes 

The guidance documents activity applies to those functions and interfaces which are related to the security of 
the TOE. The secure configuration of the TOE is described in the ST. 

13.7 JZ Evaluation of Administrator guidance (AGD_ADM.1) 

13.7.2.1 Objecljves 

The objective of this sub-activity is to determine whether the administrator guidance describes how to 
administer the TOE in a secure manner. 

13.7.2.2 Input 

The evaluation evidence for this sub-activity is; 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 
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e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures; 

g) the life-cycle definition. 

13.7.2.3 Application notes 

The term "administrator" is used to indicate a human user who is trusted to perform security critical operations 
within the TOE, such as setfing TOE configuration parameters. The operations may affect the enforcement of 
the TSP, and the administrator therefore possesses specific privileges necessary to perform those operations. 
The role of the admtnistrator(s) has to be clearly distinguished from the role of non-administrative users of the 
TOE. 

There may be different administrator roles or groups defined in the ST that are recognised by the TOE and 
that can interact with the TSF such as auditor, administrator, or daily-management. Each role can encompass 
an extensive set of capabilities, or can be a single one. The capabilities of these roles and their associated 
privileges are described in the FMT class. Different administrator roles and groups should be taken into 
consideration by the administrator guidance. 

13.7.2.4 Action AGD_ADM.1. IE 

13.7.2.4.1 Work unit 4:AGD_ADM.1-1 

ISO/IEC 15408-3 AGD_ADM.1.1C: The administrator guidance stiall describe the administrative functions and 
interfaces available to the administrator of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes the administrative 
security functions and interfaces available to the administrator of the TOE. 

The administrator guidance should contain an overview of the security functionality that is visible at the 
administrator interfaces. 

The administrator guidance should identify and describe the purpose, behaviour, and interrelationships of the 
administrator security interfaces and functions. 

For each administrator security interface and function, the administrator guidance should: 

a) describe the method(s) by which the interface is invoked (e.g. command-line, programming-language 
system calls, menu selection, command button); 

b) describe the parameters to be set by the administrator, their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

13.7.2.4.2 Workunlt4:AGD_ADM.1.2 

ISO/IEC 15408-3 AGD_ADM.1.2C: The administrator guidance shall describe how to administer the TOE in a 
secure manner. 

The evaluator shall examine the administrator guidance to determine that it describes how to administer the 
TOE in a secure manner. 

The administrator guidance describes how to operate the TOE according to the TSP in an IT environment that 
is consistent with the one described in the ST. 
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13.7.2.4.3 Workunit4:AGD_ADM.1-3 

ISO/IEC 15408-3 AGD_ADM.1.3C: The administrator guidance shall contain warnings about functions and 
privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the administrator guidance to determine that it contains warnings about functions 
and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges to make use of the different 
functions of the TOE. This means that some users may be authorised to perform certain functions while other 
users may not be so authorised. These functions and privileges should be described by the administrator 
guidance. 

The administrator guidance identifies the functions and privileges that must be controlled, the types of controls 
required for them, and the reasons for such controls. Warnings address expected effects, possible side effects, 
and possible interactions with other functions and privileges. 

1 3.7.2.4.4 Work unit 4:AGD_ADM.1 -4 

ISO/IEC 15408-3 AGD_ADM.1.4C: The administrator guidance shall describe all assumptions regarding user 
behaviour that are relevant to secure operation of the TOE. 

The evaluator shall examine the administrator guidance to determine that it describes all assumptions 
regarding user behaviour that are relevant to the secure operation of the TOE. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the administrator guidance. 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

1 3.7.2.4.5 Work unit 4:AGD_ADM.1 -5 

ISO/IEC 15408-3 AGD_ADM.1.5C: The administrator guidance shall describe all security parameters under 
the control of the administrator, indicating secure values as appropriate. 

The evaluator shall examine the administrator guidance to determine that it describes all security parameters 
under the control of the administrator indicating secure values as appropriate. 

For each security parameter, the administrator guidance should describe the purpose of the parameter, the 
valid and default values of the parameter, and secure and insecure use settings of such parameters, both 
individually or in combination. 

1 3.7.2.4.6 Work unit 4: AGD_ADM.1 -6 

ISO/IEC 15408-3 AGD_ADM.1.6C: The administrator guidance shall describe each type of security-relevant 
event relative to the administrative functions that need to be performed, including changing the security 
characteristics of entities under the control of the TSF. 

The evaluator shall examine the administrator guidance to determine that it describes each type of security- 
relevant event relative to the administrative functions that need to be performed, including changing the 
security characteristics of entities under the control of the TSF. 

All types of security-relevant events are detailed, such that an administrator knows what events may occur 
and what action (if any) the administrator may have to take in order to maintain security. Security-relevant 
events that may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user 
records, such as when a user account is removed when the user leaves the organisation) are adequately 
defined to allow administrator intervention to maintain secure operation. 
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13.7.2.4,7 Workunit4:AGD ADM.1-7 



ISd/lEC 15408-3 AGD_ADM.1.7C: The administrator guidance sha// be consistent with all other 
documentation supplied for evaluation. 

The evaluator shall examine the administrator guidance to determine that it is consistent with all other 
documents supplied for evaluation. 

The ST in particular may contain detailed information on any warnings to the TOE administrators with regard 
to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A. 3, Consistency analysrs. 

13.7.2.4.8 Workunit4:AGD_ADM.1-8 

ISO/IEC 15408-3 AGD_ADM.1.8C: The administrator guidance shall describe all security requirements for the 
IT environment that are relevant to the administrator. 

The evaluator shall examine the administrator guidance to determine that it describes all IT security 
requirements for the IT environment of the TOE that are relevant to the administrator. 

!f the ST does not contain IT security requirements for the IT environment, this worl< unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any Organisational security policies. 

The evaluator should analyse the security requirements for the IT environment of the TOE (optional statement 
in the ST) and compare them with the administrator guidance to ensure that all security requirements of the 
ST that are relevant to the administrator are described appropriately in the administrator guidance. 

13.7.3 Evaluation of User guidance (AGD_USR.1) 

13.7.3.1 Objectives 

The objectives of this sub-activity are to determine whether the user guidance describes the security functions 
and interfaces provided by the TSF and whether this guidance provides instructions and guidelines for the 
secure use of the TOE. 

13.7.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the user guidance; 

e) the administrator guidance; 

f) the secure installation, generation, and start-up procedures. 

13.7.3.3 Application notes 

There may be different user roles or groups defined in the ST that are recognised by the TOE and that can 
interact with the TSF. The capabilities of these roles and their associated privileges are described in the FMT 
class. Different user roles and groups should be taken into consideration by the user guidance. 
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13.7.3.4 Action AGD_USR.1. IE 

13.7.3.4.1 Work unit 4:AGD_USR.1-1 

ISO/IEC 15408-3 AGD_USR.1.1C: The user guidance shall describe the functions and interfaces available to 
the non-administrative users of the TOE. 

The evaluator shall examine the user guidance to determine that it describes the security functions and 
interfaces available to the non-administrative users of the TOE. 

The user guidance should contain an overview of the security functionality that is visible at the user interfaces. 

The user guidance should identify and describe the purpose of the security interfaces and functions. 

13.7.3.4.2 Work unit 4:AGD_USR.1-2 

ISO/IEC 15408-3 AGD_USR.1.2C: The user guidance shall deschbe the use of user-accessible security 
functions provided by the TOE. 

The evaluator shall examine the user guidance to determine that it describes the use of user-accessible 
security functions provided by the TOE. 

The user guidance should identify and describe the behaviour and interrelationship of the security interfaces 
and functions available to the user. 

If the user is allowed to invoke a TOE security function, the user guidance provides a description of the 
interfaces available to the user for that function. 

For each interface and function, the user guidance should: 

a) describe the method(s} by which the interface is invoked (e.g. command-line, programming-language 
system call, menu selection, command button) ; 

b) describe the parameters to be set by the user and their valid and default values; 

c) describe the immediate TSF response, message, or code returned. 

13.7.3.4.3 Workunit4:AGD_USR.1-3 

ISO/IEC 15408-3 AGD_USR.1 .3C: The user guidance shall contain warnings about user-accessible functions 
and privileges that should be controlled in a secure processing environment. 

The evaluator shall examine the user guidance to determine that it contains warnings about user-accessible 
functions and privileges that should be controlled in a secure processing environment. 

The configuration of the TOE may allow users to have dissimilar privileges in making use of the different 
functions of the TOE. This means that some users are authorised to perform certain functions, while other 
users may not be so authorised. These user-accessible functions and privileges are described by the user 
guidance. 

The user guidance should identify the functions and privileges that can be used, the types of commands 
required for them, and the reasons for such commands. The user guidance should contain warnings regarding 
the use of the functions and privileges that must be controlled. Warnings should address expected effects, 
possible side effects, and possible interactions with other functions and privileges. 
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13.7.3.4.4 Work unit 4:AGD USR.1-4 



ISO/IEC 15408-3 AGD_USR.1 .4C: The user guidance shall clearly present all user responsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

The evaluator shall examine the user guidance to determine that it presents all user respronsibilities necessary 
for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the 
statement of TOE security environment. 

Assumptions about the user behaviour may be described in more detail in the statement of the TOE security 
environment of the ST. However, only the information that is of concern to the secure operation of the TOE 
need be included in the user guidance. 

The user guidance should provide advice regarding effective use of the security functions (e.g. reviewing 
password composition practices, suggested frequency of user file backups, discussion on the effects of 
changing user access privileges). 

An example of a user's responsibility necessary for secure operation is that users will keep their passwords 
secret. 

The user guidance should indicate whether the user can invoke a function or whether the user requires the 
assistance of an administrator. 

13.7.3.4.5 Workunit4:AGD_USR.1-5 

tSO/lEC 15408-3 AGD_USR.1.5C: The user guidance shall be consistent with all other documentation 
supplied for evaluation. 

The evaiuator shall examine the user guidance to determine that it is consistent with all other documentation 
supplied for evaluation. 

The evaluator ensures that the user guidance and all other documents supplied for evaluation do not 
contradict each ottier. This is especially true if the ST contains detailed information on any warnings to the 
TOE users with regard to the TOE security environment and the security objectives. 

For guidance on consistency analysis see A. 3, Consistency analysis. 

13.7.3.4.6 Workunit4:AGD_USR.1-6 

ISO/IEC 15408-3 AGD_USR.1.6C: The user guidance shall describe all security requirements for the IT 
environment that are relevant to the user. 

The evaluator shall examine the user guidance to determine that it describes all security requirements for the 
IT environrnent of the TOE that are relevant to the user. 

If the ST does not contain IT security requirements for the IT environment, this work unit is not applicable, and 
is therefore considered to be satisfied. 

This work unit relates to IT security requirements only and not to any organisational security policies. 

The evaluator should analyse the security requirements for the IT environment 0|f the TOE (optional statement 
in the ST) and compare that with the user guidance to ensure that all security requirements of the ST, that are 
relevant to the user, are described appropriately in the user guidance. 

13.8 Life cycle support activity 

The purpose of the life-cycle support activity is to determine the adequacy of the procedures the developer 
uses during the development and maintenance of the TOE. These procedures include the security measures 
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used throughout TOE development, the life-cycle model used by the developer, and the tools used by the 
developer throughout the life-cycle of the TOE. 

Developer security procedures are intended to protect the TOE and its associated design infonmation from 
interference or disclosure. Interference in the developement process may ^llow the deliberate introduction of 
vulnerabilities. Disclosure of design information may allow vulnerabilities to be more easily exploited. The 
adequacy of the procedures will depend on the nature of the TOE and the development process. 

Poorjy controlled development and maintenance of the TOE can result in vulnerabilities in the implementation. 
Conformance to a defined life-cycle mode! can help to improve controls in this area. 

The use of well-defined development tools help to ensure that vulnerabilities are not inadvertently introduced 
during refinement. 

1 3.8.1 Evaluation of Development security (ALC_DVS.1) 

13.8.1.1 Objectives 

The objective of this sub-activity is to determine whether the developei^s security controls on the development 
environment are adequate to provide the confidentiality and integrity of the TOE design and implementation 
that is necessary to ensure that secure operation of the TOE is not compromised. 

13.8.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the development security documentation. 

in addition, the evaluator may need to examine other deliverables to determine that the security controls are 
well-defined and followed. Specifically, the evaluator may need to examine the developer's configuration 
management documentation (the input for the ACM_CAP.4 Generation support and acceptance procedures 
and ACM_SCP.2 Problem tracking CM coverage sub-activities). Evidence that the procedures are being 
applied is also required. 

13.8.1.3 Action ALC_DVS.1. IE 

13.8.1.3.1 WoFk unit 4:ALC_DVS.1 -1 

ISO/IEC 15408-3 ALC_DVS.1.1C: The development security documentation sfiall describe all the physical, 
procedural, personnel, and other security measures that are necessary to protect the conridentiallty and 
integrity of the TOE design and implementation in its development environment. 

The evaluator shall examine the development security documentation to determine that it details all security 
mecisures used in the development environment that are necessary to protect the confidentiality and integrity 
of the TOE design and implementation. 

The evaluator determines what is necessary by first referring to the ST for any information that may assist in 
the determination of necessary protection, especially the subclauses on threats, organisational security 
policies and assumptions, although there may be no information provided explicitly. The statement of security 
objectives for the environment may also be useful in this respect. 

If no explicit information is available from the ST the evaluator will need to make a determination of the 
necessary measures, based upon a consideration of the intended environment for the TOE. In cases where 
the developer's measures are considered less than what is necessary, a clear justification should be provided 
for the assessment, based on a potential exploitable vulnerability. 
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The following types of security measures are considered by the evaluator when examining the documentation: 

a) physical, for example physical access controls used to prevent unauthorised access to the TOE 
development environment (during normal working hours and at other times); 

b) procedural, for example covering: 

• granting of access to the development environment or to specific parts of the environment such as 
development machines 

• revocation of access rights when a person leaves the development team 

• transfer of protected material out of the development environment 

• admitting and escorting visitors to the development environment 

• roles and responsibilities in ensuring the continued application of security measures, and the detection 
of security breaches. 

c) personnel, for example any controls or checks made to establish the trustworthiness of new development 

staff; 

d) other security measures, for example the logical protections on any development machines. 

The development security documentation should identify the locations at which development occurs, and 
describe the aspects of development performed, along with the security measures applied at each location. 
For example, development could occur at multiple facilities within a single building, multiple buildings at the 
same site, or at multiple sites. Development includes such tasks as creating multiple copies of the TOE, where 
applicable. This work-unit should not overlap with those for Delivery (ADO_DEL), but the evaluator should 
ensure that all aspects are covered by one sub-activity or the other. 

In addition, the development security documentation may describe different security measures that can be 
applied to different aspects of development in terms of their performance and the required inputs and outputs. 
For example, different procedures may be applicable to the development of different portions of the TOE, or to 
different stages of the development process. 

13.8.1.3.2 Workunit4:ALC_DVS.1-2 

The evaluator shall examine the development confidentiality and integrity policies in order to determine the 
sufficiency of the security measures employed. 

These include the policies governing: 

a) what information relating to the TOE development needs to be kept confidential, and which members of 
the development staff are allowed to access such material; 

b) what material must be protected from unauthorised modification in order to preserve the integrity of the 
TOE, and which members of the development staff are allowed to modify such material. 

The evaluator should determine that these policies are described in the development security documentation, 
that the security measures employed are consistent with the policies, and that they are complete. 

It should be noted that configuration management procedures will help protect the integrity of the TOE and the 
evaluator should avoid overlap with the work-units conducted for the CM capabilities (ACM_CAP) sub-activity. 
For example, the CM documentation may describe the security procedures necessary for controlling the roles 
or individuals who should have access to the development environment and who may modify the TOE. 

Whereas the CM capabilities (ACM_CAP) requirements are fixed, those for Development security (ALC_DVS), 
mandating only necessary measures, are dependent on the nature of the TOE, and on information that may 
be provided in the Security Environment subclause of the ST. For example, the ST may identify an 
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organisational security policy that requires the TOE to be developed by staff who have security clearance. The 
evaluators would then determine that such a policy had been applied under this sub-activity. 

13.8.1.3.3 Workunit4:ALC_DVS.1-3 

ISO/lEC 15408-3 ALC_DVS.1 .2C: The development security documentation sliall provide evidence that these 
security measures are followed during the development and maintenance of the TOE. 

The evatuator shall check the development security documentation to determine that documentary evidence 
that would be produced as a result of application of the procedures has been generated. 

Where documentary evidence is produced the evaluator inspects it to ensure compliance with procedures. 
Examples of the evidence produced may include entry logs and audit trails. The evaluator may choose to 
sample the evidence. 

For guidance on sampling see A.2, Sampling. 

13.8.1.4 Action ALC_DVS.1.2E 

13.8.1.4.1 Workunit4:ALC_DVS.1-4 

The evaluator shall examine the development security documentation and associated evidence to determine 
that the security measures are being applied. 

This work unit requires the evaluator to determine that the security measures described in the development 
security documentation are being followed, such that the integrity of the TOE and the confidentiality of 
associated documentation is being adequately protected. For example, this could be determine'! by 
examination of the documentary evidence provided. Documentary evidence should be supplemented by 
visiting the development environment. A visit to the development environment will. allow the evaluator to: 

a) observe the application of security measures (e.g. physical measures); 

b) examine documentary evidence of application of procedures; 

c) interview development staff to check awareness of the development security policies and procedures, 
and their responsibilities. 

A development site visit is a useful means of gaining confidence in the measures being used. Any decision not 
to make such a visit should be determined in consultation with the overseer. 

For guidance on site visits see A.5, Site Visits. 

13.8.2 Evaluation of Life cycle definition (ALC_LCD.1) 

13.8.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has used a documented model of the 
TOE life-cycle. 

13.8.2.2 Input 

The evaluation evidence for this sub-activity is; 

a) the ST; 

b) the life-cycle definition documentation. 
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1 3.8.2.3 Action ALC_LCD.1 .1 E 

13.8.2.3.1 Workunit4:ALC_LCD.1-1 

ISO/IEC 15408-3 ALC_LCD.1.1C: The life-cycle definition documentation sha// describe the model used to 
develop and maintain the TOE. 

The evaluator shall examine the documented description of the life-cycle model used to determine that it 
covers the development and maintenance process. 

A life-cycle model encompasses the procedures, tools and tehniques used to develop and maintain the TOE. 
The description of the life-cycle model should include information on the procedures, tools and techniques 
used by the developer (e.g. for design, coding, testing, bug-fixing). It should describe overall management 
structure governing the application of the procedures (e.g. an identification and description of the individual 
responsibilities for each of the procedures required by the development and maintenance process covered by 
the life-cycle model). ALC_LCD.1 Developer defined life-cycle model does not require the model used to 
conform to any standard life-cycle model. 

13.8.2.3.2 Work unit 4:ALC_LCD.1-2 

ISO/IEC 15408-3 ALC_LCD.1.2C: The life-cycle model shall provide for the necessary control over the 
development and maintenance of the TOE. 

The evaluator shall examine the life-cycle model to determine that use of the procedures, tools and 
techniques described by the life-cycle model will make the necessary positive contribution to the development 
and maintenance of the TOE. 

The information provided in the life-cycle model gives the evaluator assurance that the development and 
maintenance procedures adopted would minimise the likelihood of security flaws. For example, if the life-cycle 
model described the review process, but did not make provision for recording changes to components, then 
the evaluator may be less confident that errors will not be introduced into the TOE. The evaluator may gain 
further assurance by comparing the description of the model against an understanding of the development 
process gleaned from performing other evaluator actions relating to the TOE development (e.g. those actions 
covered under the ACM activity). Identified deficiencies in the life-cycle model will be of concern if they might 
reasonably be expected to give rise to the introduction of flaws into the TOE, either accidentally or deliberately. 

ISO/IEC 15408 does not mandate any particular development approach, and each should be judged on merit. 
For example, spiral, rapid-prototyping and waterfall approaches to design can all be used to produce a quality 
TOE if applied in a controlled environment. 

13.8.3 Evaluation of Tools and techniques (ALC_TAT,1) 

13.8.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer has used well-defined development 
tools (e.g. programming languages or computer-aided design (CAD) systems) that yield consistent and 
predictable results. 

13.8.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the development tool documentation; 

b) the subset ofthe implementation representation. 
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13.8.3.3 Application notes 

This work may be performed in paratlei with the ADVJMP.I Subset of the implementation of the TSF sub- 
activity, specifically with regard to determining the use of features in the tools that will affect the object code 
{e.g. compilation options). 

13.8.3.4 Action ALC_TAT.1.1E 

1 3.8.3.4.1 Work unit 4:ALC_TAT.1 -1 

ISO/IEC 15408-3 ALC_TAT.1 IC: All development tools used for implementation shall be well-defined. 

The evaluator shall examine the development tool documentation provided to determine that all development 
tools are well-defined. 

For example, a well-defined language, compiler or CAD system may be considered to be one that conforms to 
a recognised standard, such as the ISO standards. A well-defined language is one that has a clear and 
complete description of its syntax, and a detailed description of the semantics of each construct. 

13.8.3.4.2 Work unit4:ALC_TAT.1.2 

ISO/IEC 15408-3 ALC_TAT.1.2C: The documentation of the development tools shall unambiguously define 
the meaning of all statements used in the implementation. 

The evaluator shall examine the documentation of development tools to determine that it unambiguously 
defines the meaning of all statements used in the implementation. 

The development tool documentation (e.g. programming language specifications and user manuals) should 
cover all statements used in the implementation representation of the TOE, and for each such statement 
provide a clear and unambiguous definition of the purpose and effect of that statement. This work may be 
performed in parallel with the evaluator's examination of the implementation representation performed during 
the ADV_IMP.1 Subset of the implementation of the TSF sub-activity. The key test the evaluator should apply 
is whether or not the documentation is sufficiently clear for the evaluator to be able to understand the 
implementation representation. The documentation should not assume {for example) that the reader is an 
expert in the programming language used. 

Reference to the use of a documented standard is an acceptable approach to meet this requirement, provided 
that the standard is available to the evaluator. Any differences from the standard should be documented. 

The critical test is whether the evaluator can understand the TOE source code when performing source code 
analysis covered in the Implementation representation (ADVJMP) sub-activity. However, the followfng 
checklist can additionally be used in searching for problem areas: 

a) In the language definition, phrases such as "the effect of this construct is undefined" and terms such as 
"implementation dependent" or "erroneous" may indicate ill-defined areas; 

b) Aliasing (allowing the same piece of memory to be referenced in different ways) is a common source of 
ambiguity problems; 

c) Exception handling (e.g. what happens after memory exhaustion or stack overflow) is often poorly defined. 

Most languages in common use, however well designed, will have some problematic constructs. If the 
implementation language is mostly well defined, but some problematic constructs exist, then an inconclusive 
verdict should be assigned, pending examination of the source code. 

The evaluator should verify, during the examination of source code, that any use of the problematic constructs 
does not introduce vulnerabilities. The evaluator should also ensure that constructs precluded by the 
documented standardare not used. 
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13.8.3.4.3 Work unit 4:ALC TAT.I-S 



ISO/IEC 15408-3 ALC_TAT.1.3C: The documentation of the development tools shall unambiguously define 
the meaning of all implementation-dependent options. 

The evaluator shall examine the development tool documentation to determine that it unambiguously defines 
the meaning of all implementation-dependent options. 

The documentation of software development tools should include definitions of implementation-dependent 
options that may affect the meaning of the executable code, and those that are different from the standard 
language as documented. Where source code is provided to the evaluator, information should also be 
provided on compilation and linking options used. 

The documentation for hardware design and development tools should describe the use of all options that 
affect the output from the tools (e.g. detailed hardware specifications, or actual hardware). 

13.9 Tests activity 

The purpose of this activity is to determine, by independently testing a subset of the TSF, whether TSF 
behaves as specified In the design documentation and in accordance with the TOE security functional 
requirements specified in the ST. This is accomplished by determining that the developer has tested the TSF 
against its functional specification and high-level design, gaining confidence in those test results by performing 
a sample of the developer's tests, and by independently testing a subset of the TSF. 

13.9.1 Application notes 

The size and composition of the evaluator's test subset depends upon several factors discussed in the 
independent testing (ATE_IND.2 Independent testing - sample) sub-activity. One such factor affecting the 
composition of the subset Is Known public domain weaknesses, information about which the evaluator needs 
access (e.g. from a scheme). 

ISO/IEC 15408 has separated coverage and depth from functional tests to increase the flexibility when 
applying the components of the families. However, the requirements of the families are intended to be applied 
together to confirm that the TSF operates according to its specification. This tight coupling of families has led 
to some duplication of evaluator work effort across sub-activities. These application notes are used to 
minimize duplication of text between sub-activities of the same activity and EAL. 

13.9.1.1 Understanding the expected behaviour of the TOE 

Before the adequacy of test documentation can be accurately evaluated, or before new tests can be created, 
the evaluator has to understand the desired expected behaviour of a security function in the context of the 
requirements it is to satisfy. 

The evaluator may choose to focus on one security function of the TSF at a time. For each security function, 
the evaluator examines the ST requirement and the relevant parts of the functional specification, high-level 
design and guidance documentation to gain an understanding of the way the TOE is expected to behave. 

With an understanding of the expected behaviour, the evaluator examines the test plan to gain an 
understanding of the testing approach. In most cases, the testing approach will entail a security function being 
stimulated at either the external or internal interfaces and its responses are observed. However, there may be 
cases where a security function cannot be adequately tested at an interface (as may be the case, for instance, 
for residual information protection functionality); in such cases, other means will need to be employed. 
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13.9.1 .2 Testing vs. alternate approaches to verify the expected behaviour of a security function 

In cases where it is impractical or inadequate to test at an interface, the test plan should identify the alternate 
approach to verify expected behaviour. It is the evaluator's responsibility to determine the suitability of the 
alternate approach. However, the following should be considered when assessing the suitability of alternate 
approaches: 

a) an analysis of the implementation representation to determine that the required behaviour should be 
exhibited by the TOE is an acceptable alternate approach. This could mean a code inspection for a 
software TOE or perhaps a chip mask inspection for a hardware TOE, 

b) it is acceptable to use evidence of developer integration or module testing, even if the EAL is not 
commensurate with evaluation exposure to the low-level design or implementation. If evidence of 
developer integration or module testing is used in verifying the expected behaviour of a security function, 
care should be given to confirm that the testing evidence reflects the current implementation of the TOE. 
If the subsystem or modules have been changed since testing occurred, evidence that the changes were 
tracked and addressed by analysis or further testing will usually be required. 

It should be emphasized that supplementing the testing effort with alternate approaches should only be 
undertaken when both the developer and evaluator determine that there exists no other practical means to 
test the expected behaviour of a security function. This alternative is made available to the developer to 
minimize the cost {time and/or money) of testing under the circumstances described above; it is not designed 
to give the evaluator more latitude to demand unwarranted additional information about the TOE, nor to 
replace testing in general. 

13.9.1.3 Verifying the adequacy of tests 

Test pre-requisites are necessary to establish the required initial conditions for the test. They may be 
expressed in terms of parameters that must be set or in terms of test ordering in cases where the completion 
of one test establishes the necessary pre-requisites for another test. The evaluator must determine that the 
pre-requisites are complete and appropriate in that they will not bias the observed test results towards the 
expected test results. 

The test steps and expected results specify the actions and parameters to be applied to the interfaces as well 
as how the expected results should be verified and what they are. The evaluator must determine that the test 
steps and expected results are consistent with the functional specification and the high-level design. The tests 
must verify behaviour documented in these specifications. This means that each security functional behaviour 
characteristic explicitly described in the functional specification and high-level design should have tests and 
expected results to verify that behaviour. 

Although all of the TSF has to be tested by the developer, exhaustive specification testing of the interfaces is 
not required. The overall aim of this activity is to determine that each security function has been sufficiently 
tested against the behavioural claims in the functional specification and high-level design. The test procedures 
wit! provide insight as to how the security functions have been exercised by the developer during testing. The 
evaluator wilt use this information when developing additional tests to independently test the TOE. 

13.9.2 Evaluation of Coverage (ATE_C0V.2) 

13.9.2.1 Objectives 

The objective of this sub-activity rs to determine whether the testing (as documented) is sufficient to establish 
that the TSF has been systematically tested against the functional specification. 

13.9.2.2 Input 

a) the ST; 

b) the functional specification; 

c) the test documentation; 

d) the test coverage analysis. 
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13.9.2.3 Action ATE„C0V.2.1E 

1 3.9.2.3.1 Work unit 4: ATE_C0V.2-1 

tSO/lEC 15408-3 ATE_C0V.2.1C: The analysis of the test coverage shall demonstrate the correspondence 
between the tests identified in the test documentation and the TSF as described in the functional specification. 

The evaluator shall examine the test coverage analysis to determine that the correspondence between the 
tests identified in the test documentation and the functional specification is accurate. 

Correspondence may lake the form of a table or matrix, In some cases mapping may be sufficient to show test 
correspondence. In other cases a rationale (typically prose) may have to supplement the correspondence 
analysis provided by the developer. 

Figure 10 displays a conceptual framework of the correspondence between security functions described in the 
functional specification and the tests outlined in the test documentation used to test them. Tests may involve 
one or multiple security functions depending on the test dependencies or the overall goal of the test being 
performed. 

The identification of the tests and the security functions presented in the test coverage analysis has to be 
unambiguous. The test coverage analysis will allow the evaluator to trace the identified tests back to the test 
documentation and the particular security function being tested back to the functional specification. 

13.9.2.3.2 Work unit 4:ATE_C0V.2-2 

The evaluator shall examine the test plan to determine that the testing approach for each security function of 
the TSF is suitable to demonstrate the expected behaviour. 

Guidance on this work unit can be found in: 

a) Understanding the expected behaviour of the TOE 

b) Testing vs. alternate approaches to verify the expected behaviour of a security function 

13.9.2.3.3 Work unit 4:ATE_COV.2-3 

The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and 
expected result(s) adequately test each security function. 

Guidance on this work units, as it pertains to the functional specification, can be found in: 

a) Verifying the adequacy of tests 

13.9.2.3.4 Workunlt4:ATE_COV.2-4 

ISO/IEC 15408-3 ATE_COV.2.2C: The analysis of the test coverage shall demonstrate that the 
conrespondence between the TSF as described in the functional specification and the tests identified in the 
test documentation is complete. 

The evaluator shall examine the test coverage analysis to determine that the correspondence between the 
TSF as described in the functional specification and the tests identified in the test documentation is complete. 

All security functions and interfaces that are described in the functional specification have to be present in the 
test coverage analysis and mapped to tests in order for completeness to be claimed, although exhaustive 
specification testing of interfaces is not required. As Figure 10 displays, all the security functions have tests 
attributed to them and therefore complete test coverage is depicted in this example. Incomplete coverage 
would be evident if a security function was identified in the test coverage analysis and no tests could be 
attributed to it. 
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Figure 13 - A conceptual framework of the test coverage analysis 

13.9.3 Evaluation of Depth (ATE_DPT.1) 

13.9.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer has tested the TSF against its high- 
level design. 

13.9.3.2 Input 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the test documentation; 

e) the depth of testing analysts. 
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13.9.3.3 Action ATE_DPT.1.1E 

13.9.3.3.1 Work unit 4:ATE_DPT.1 -1 

ISO/IEC 15408-3 ATE_DPT.1.1C: The depth analysis shall demonstrate that the tests Identified in the test 
documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design. 

The evaluator shall examine the depth of testing analysis for a mapping between the tests identified in the test 
documentation and the high-level design. 

The depth of testing analysis identifies all subsystems described in the high-level design and provides a 
mapping of the tests to these subsystems. Correspondence may take the form of a table or matrix. In some 
cases the mapping may be sufficient to show test correspondence. In other cases a rationale (typically prose) 
may have to supplement the mapping evidence provided by the developer. 

All design details specified in the high-level design that map to and satisfy TOE security requirements are 
subject to testing and hence, should be mapped to test documentation. Figure 1 1 displays a conceptual 
framework of the mapping between subsystems described in the high-level design and the tests outlined in 
the TOE'S test documentation used to test them. Tests may involve one or multiple security functions 
depending on the test dependencies or the overall goal of the test being performed. 

13.9.3.3.2 Work unit4:ATE_DPT.1-2 

The evaiuator shall examine the developer's test plan to determine that the testing approach for each security 
function of the TSF is suitable to demonstrate the expected behaviour. 

Guidance on this work unit can be found in: 

a) Understanding the expected behaviour of the TOE 

b) Testing vs. alternate approaches to verify the expected behaviour of a security function 

Testing of the TSF may be performed at the external interfaces, internal interfaces, or a combination of both. 
Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the security 
functions. Specifically the evaluator determines whether testing at the internal interfaces for a security function 
is necessary or whether these internal interfaces can be adequately tested (albeit implicitly) by exercising the 
externa! interfaces. This determination is left to the evaluator, as is its justification. 

13.9.3.3.3 Work unit4:ATE„DPT.1-3 

The evaluator shall examine the test procedures to determine that the test pre-requisites, test steps and 
expected result(s) adequately test each security function. 

Guidance on this work units, as it pertains to high level design, can be found in: 

a) Verifying the adequacy of tests 

1 3.9.3.3.4 Work unit 4:ATE_DPT.1 -4 

The evaluator shall check the depth of testing analysis to ensure that the TSF as defined in the high-level 
design is completely mapped to the tests in the test documentation. 

The depth of testing analysis provides a complete statement of correspondence between the high-level design 
and the test plan and procedures. All subsystems and internal interfaces described in the high-level design 
have to be present in the depth of testing analysis. All the subsystems and internal interface? present in the 
depth of testing analysis must have tests mapped to them in order for completeness to be claimed. As Figure 
11 displays, all the subsystems and internal interfaces have tests attributed to them and therefore complete 
depth of testing is depicted in this example. Incomplete coverage would be evident if a subsystem or internal 
interface was identified in the depth of testing analysis and no tests could be attributed to it. 



221 



IS 15671 :2006 
ISO/IEC 18045 : 2005 



Ij^pthpf testing ^n^tysi^ 



T-1 



T-3 



T-2 



/Subsystem - r^ 

fsF - ij 

(SF - 3) 



T-4 



Subsystem - 2 




J^X 



T-9 





T-5 








T-6 








T-7 








T-8 



Rationale (if required) for completeness 



T 



Test documentation 


Test- 


■1 (T- 


1) 


Test- 


■2(T- 


2) 


Test- 


•3(T- 


■3) 


Test- 


-4(T- 


■4) 


Test- 


-5(T- 


•5) 


Test- 


-6(T. 


■6) 


Test 


-7(T- 


■7) 


Test 


-8(T- 


■8) 


Test 


-9(T- 


■9) 



I 



High-level design 



Subsystem-1 (SF-l,SF-3) 
Subsystem - 2 (SF - 2, SF - 4) 



Functional specification 

Security Function - 1 (SF - 1 ) 
Security Function - 2 (SF - 2) 
Security Function - 3 (SF - 3) 
Security Function - 4 (SF - 4) 



Figure 14 - A conceptual framework of the depth of testing analysis 

13.9.4 Evaluation of Functional tests (ATE.FUN.I) 

13.9.4.1 Objectives 

The objective of this sub-activity is to determine whether the developer's functional test documentation is 
sufficient to demonstrate that security functions perform as specified. 
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13.9.4.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the test documentation; 

d) the test procedures. 

13.9.4.3 Application notes 

The extent to which the test documentation is required to cover the TSF is dependent upon the coverage 
assurance component. 

For the developer tests provided, the evaluator determines whether the tests are repeatable, and the extent to 
which the developer's tests can be used for the evaluator's independent testing effort. Any security function for 
which the developer's test results indicate that it may not perform as specified should be tested independently 
by the evaluator to determine whether or not it does. 

The test documentation will identify any instances where privileged modes are used to set up test 
conditions/cleanup for further tests. The test documentation will describe why it was necessary to use 
privileged modes to obtain the necessary conditions (e.g. efficiency of the test harness, to generate specific 
objects required for a test that unprivileged users are unable to create) and also how the privileged rpodes are 
exited prior to the conduct of the test steps demonstrating the security functionality of the TOE. Therefore, 
although the test configuration may be inconsistent with the TOE as described in the ST during the 
establishment of the test conditions the test documentation will describe how the configuration is returned to a 
state that is consistent with the configuration described in the ST for the conduct of the test steps. 

13.9.4.4 Action ATE_FUN.1.1E 

1 3.9.4.4.1 Work unit 4:ATE_FUN,1 -1 

ISO/IEC 15408-3 ATE_FUN.I.1C. The test documentation shall consist of test plans, test procedure 
descriptions, expected test results and actual test results. 

The evaluator shall check that the test documentation includes test plans, test procedure descriptions, 
expected test results and actual test results. 

13.9.4.4.2 Workunlt4:ATE_FUN.1-2 

ISO/IEC 1 5408-3 ATE_FUN.1 .2C: The test plans shall identify the security functions to be tested and describe 
the goal of the tests to be performed. 

The evaluator shall checV; that the test plan identifies the security functions to be tested. 

One method that could be used to identify the security function to be tested is a reference to the appropriate 
part(s) of the functional specification that specifies the particular security function. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling, 

«.9.4.4.3 Work unit 4:ATE_FUN.1-3 

The evaluator shall examine the test plan to determine that it describes the goal of the tests perfonmed. 
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The test plan provides information about how the security functions are tested and the test configuration in 
which testing occurs. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

1 3.9.4.4.4 Work unit 4:ATE_FUN.1 -4 

The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the 
configuration identified for evaluation in the ST. 

The TOE referred to in the developer's test plan should have the same unique reference as established by the 
CM capabilities (ACM_CAP).* sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation. The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator verifies that there are test configurations identified in the developer test documentation that ate 
consistent with each evaluated configuration described in the ST. 

The evaluator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

13.9.4.4.5 Workunlt4:ATE_FUN.1-5 

The evaluator shall examine the test plan to determine that it is consistent with the test procedure descriptions. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A.3, Consistency 
analysis. 

13.9.4.4.6 Workunit4:ATE_FUN.1-6 

ISO/IEC 15408-3 ATE_FUN.1 .3C: The test procedure descriptions shall ider}tify the tests to be perforrr^ed arid 
describe the scenarios for testing each security function. These scenarios shall include any ordering 
dependencies on the results of other tests. 

The evaluator shall check that the test procedure descriptions identify each security function behaviour to be 
tested. 

One method that may be used to identify the security function behaviour to be tested is a reference to the 
appropriate part(s) of the design specification that specifies the particular behaviour to be tested. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

13.9.4.4.7 Work unlt4:ATE_FUN.1.7 

The evaluator shall examine the test procedure descriptions to determine that sufficient instructions are 
provided to establish reproducible initial test conditions including ordering dependencies if any. 

Some steps may have to be performed to establish initial conditions. For example, user accounts need to be 
added before they can be deleted. An example of ordering dependencies on the results of other tests is the 
need to test the audit function before relying on it to produce audit records for another security mechanism 
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such as access control. Another example of an ordering dependency would be where one test case generates 
a file of data to be used as input for another test case. 

The ©valuator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

13.9.4.4.8 Workunit4;ATE_FUN.1-8 

The evaiuator shall examine the test procedure descriptions to determine that sufTicient instructions are 
provided to have a reproducible means to stimulate the security functions and to observe their behaviour. 

Stimulus is usually provided to a security function externally through the TSFl. Once an input (stimulus) is 
provided to the TSFl, the behaviour of the security function can then be observed at the TSFl. Reproducibility 
is not assured unless the test procedures contain enough detail to unambiguously describe the stimulus and 
the behaviour expected as a result of this stimulus. 

The evaiuator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

13.9.4.4.9 Workunit4:ATE_FUN.1-9 

The evaiuator shall examine the test procedure descriptions to determine that they are consistent with the test 
procedures. 

If the test procedure descriptions are the test procedures, then this work unit is not applicable and is therefore 
considered to be satisfied. 

The evaiuator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. For guidance on consistency analysis see A.3, Consistency 
analysis. 

13.9.4.4.10 Work unit 4:ATE_FUN.1-10 

ISO/IEC 15408-3 ATE_FUN.1.4C: The expected test results shaK show the anticipated outputs from a 
successful execution of the tests. 

The evaiuator shall examine the test documentation to determine that sufficient expected tests results are 
included. 

The expected test results are needed to determine whether or not a test has been successfully performed. 
Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the 
testing approach. 

The evaiuator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

13.9.4.4.11 Work unit4:ATE_FUN.1-11 

ISO/IEC 15408-3 ATE_FUN.1.5C: The test results from the developer execution of the tests shall demonstrate 
that each tested security function behaved as specified. 

The evaiuator shall check that the expected test results in the test documentation are consistent with the 
actual test results provided. 
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A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies 
between the results. 

It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has 
been first performed. In such cases, the developer's test documentation should describe the process to 
reduce or synthesize the actual data. 

For example, the developer may need to test the contents of a message buffer after a network connection has 
occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary 
number would have to be converted to another form of data representation in order to make the test more 
meaningful. The conversion of this binary representation of data into a higher-level representation will have to 
be described by the developer in enough detail to allow an evaluator to perform the conversion process {i.e. 
synchronous or asynchronous transmission, number of stop bits, parity, etc.). 

It should be noted thatihe description of the process used to reduce or synthesize the actual data is used by 
the evaluator not to actually perform the necessary modification but to assess whether this process is correct. 
It is up to the developer to transform the expected test results into a format that allows an easy comparison 
with the actual test results. 

The evaluator may wish to employ a sampling strategy when performing this work unit. 

For guidance on sampling see A.2, Sampling. 

If the expected and actual test results for any test are not the same, then a demonstration of the correct 
operation of a security function has not been achieved. Such an occurrence will influence the evaluator's 
independent testing effort to include testing the implicated security function. The evaluator should also 
consider increasing the sample of evidence upon which this work unit is performed. 

13.9.4.4.12 Work unit4:ATE_FUN.1-12 

The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and 
results. 

The developer testing information recorded in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing of the TOE by the developer. The intent of providing this 
information is to give a meaningful overview of the developer testing effort. It is not intended that the 
information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of 
individual tests. The intention is to provide enough detail to allow other evaluators and overseers to gain some 
insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the 
overall results of the developer testing. 

information that would typically be found in the ETR subclause regarding the developer testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested; 

b) testing approach. An account of the overall developer testing strategy employed; 

c) amount of developer testing performed. A description on the extent of coverage and depth of developer 
testing; 

d) testing results. A description of the overall developer testing results. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the developer testing effort. 



226 



IS 15671 : 2006 
ISO/IEC 18045 : 2005 

13.9.5 Evaluation of Independent testing (ATEJND.2) 

13.9.5.1 Objectives 

The goal of this activity is to determine, by independently testing a subset of the TSF, whether the TOE 
behaves as specified, and to gain confidence in the developer's test results by performing a sample of the 
developer's tests. 

13.9.5.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the user guidance; 

d) the administrator guidance; 

e) the secure installation, generation, and start-up procedures; 

f) the test documentation; 

g) the test coverage analysis; 
h) the depth of testing analysis; 
i) the TOE suitable for testing. 

13.9.5.3 Action ATE_IND.2.1E 

13.9.5.3.1 Work Unit 4:ATEJND.2-1 

ISO/IEC 15408-3 ATE_IND.2.1C: The TOE shall be suitable for testing. 

The evaiuator shall examine the TOE to determine that the test configuration is consistent with the 
configuration under evaluation as specified in the ST. 

The TOE used for evaiuator testing should have the same unique reference as established by the CM 
capabilities (ACM_CAP).* sub-activity. 

It is possible for the ST to specify more than one configuration for evaluation. The TOE may be composed of a 
number of distinct hardware and software implementations that need to be tested in accordance with the ST. 
The evaluator's TOE test configurations should be consistent with each evaluated configuration described in 
the ST. 

The evaiuator should consider the assumptions about the security aspects of the TOE environment described 
in the ST that may apply to the test environment. There may be some assumptions in the ST that do not apply 
to the test environment. For example, an assumption about user clearances may not apply; however, an 
assumption about a single point of connection to a network would apply. 

If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that 
these resources are calibrated correctly. 

13.9.5.3.2 Work unit 4:ATEJND.2-2 

The evaiuator shall examine the TOE to determine that it has been installed properly and is in a known state 
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It is possible for the evaluator to determine the state of the TOE In a number of ways. For example, previous 
successful completion of the AD0_IGS.1 Installation, generation, and start-up procedures sub-activity will 
satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed 
properly and is in a known state. If this is not the case, then the evaluator should follow the developer's 
procedures to install, generate and start up the TOE, using the supplied guidance only. 

If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work 
unit when successfully completed could satisfy work unit ADOJGS.1-2. 

1 3.9.5.3.3 Work unit 4:ATE JND.2-3 

ISO/IEC 15408-3 ATE_IND.2.2C: The developer shall provide an equivalent set of resources to those that 
were used in the developer's functional testing of the TSF. 

The evaluator shall examine the set of resources provided by the developer to determine that they are 
equivalent to the set of resources used by the developer to functionally test the TSF 

The resource set may include laboratory access and special test equipment, among others. Resources that 
are not identical to those used by the developer need to be equivalent in terms of any impact they may have 
on test results. 

13.9.5.4 Action ATEJND.2.2E 

13.9.5.4.1 Work unit 4:ATEJND.2-4 

The evaluator shall devise a test subset 

The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing 
strategy would be to have the test subset contain as many security functions as possible tested with little 
rigour. Another testing strategy would be to have the test subset contain a few security functions based on 
their perceived relevance and rigorously test these functions. 

Typically the testing approach taken by the evaluator should fall somewhere between these two extremes. 
The evaluator should exercise most of the security functional requirements identified in the ST using at least 
one test, but testing need not demonstrate exhaustive specification testing. 

The evaluator, when selecting the subset of the TSF to be tested, should consider the following factors: 

a) The developer test evidence. The developer test evidence consists of: the test coverage analysis, the 
depth of testing analysis, and the test documentation. The developer test evidence will provide insight as 
to how the security functions have been exercised by the developer during testing. The evaluator applies 
this information when developing new tests to independently test the TOE. Specifically the evaluator 
should consider: 

1 ) augmentation of developer testing for specific security function(s). The evaluator may wish to perform 
more of the same type of tests by varying parameters to more rigorously test the security function. 

2) supplementation of developer testing strategy for specific security function(s). The evaluator may 
wish to vary the testing approach of a specific security function by testing it using another test 
strategy. 

b) The number of security functions from which to draw upon for the test subset. Where the TOE includes 
only a small number of security functions, it may be practical to rigourously test all of the security 
functions. For TOEs with a targe number of security functions this will not be cost-effective, and sampling 
is required. 

c) Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be 
commensurate with that expended on any other evaluation activity. 
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The evaluator selects the security functions to compose the subset. This selection will depend on a number of 
factors, and consideration of these factors may also influence the choice of test subset size: 

a) Rigour of developer testing of the security functions. All security functions identified in the functional 
specification had to have developer test evidence attributed to them as required by ATE_C0V.2 Analysis 
of coverage. Those security functions that the evaluator determines require additional testing should be 
included in the test subset. 

b) Developer test results. If the results of developer tests cause the evaluator to doubt that a security 
function, or aspect thereof, operates as specified, then the evaluator should Include such security 
functions in the test subset. 

c) Known public domain weaknesses commonly associated with the type of TOE (e=g. operating system, 
iirewall). Know public domain weaknesses associated with the type of TOE will influence the selection 
process of the test subset. The evaluator should include those security functions that address known 
public domain weaknesses for that type of TOE in the subset (know public domain weaknesses in this 
context does not refer to vulnerabilities as such but to inadequacies or problem areas that have been 
experienced with this particular type of TOE). If no such weaknesses are known, then a more general 
approach of selecting a broad range of security functions may be more appropriate. 

d) Significance of security functions. Those security functions more significant than others in terms of the 
security objectives for the TOE should be included in the test subset. 

e) SOF claims made in the ST. All security functions for which a specific SOF claim has been made should 
be included in the test subset. 

f) Complexity of the security function. Complex security functions may require complex tests that impose 
onerous requirements on the developer or evaluator, which will not be conducive to cost-effective 
evaluations. Conversely, complex security functions are a likely area to find errors and are good 
candidates for the subset. The evaluator will need to strike a balance between these considerations. 

g) Implicit testing. Testing some security functions may often implicitly test other security functions, and their 
inclusion in the subset may maximize the number of security functions tested (albeit implicitly). Certain 
interfaces will typically be used to provide a variety of security functionality, and will tend to be the target 
of an effective testing approach. 

h) Types of interfaces to the TOE (e.g. programmatic, command-line, protocol). The evaluator should 
consider including tests for all different types of interfaces that the TOE supports. 

i) Functions that are innovative or unusual. Where the TOE contains innovative or unusual security 
functions, which may feature strongly in marketing literature, these should be strong candidates for 
testing. 

This guidance articulates factors to consider during the selection process of an appropriate test subset, but 
these are by no means exhaustive. 

For guidance on sampling see A.2, Sampling. 

13.9.5.4.2 Work unit 4:ATEJND.2-5 

The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the 
tests to be reproducible 
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With an understanding of the expected behaviour of a security function, from the ST and the functional 
specification, the evaluator has to determine the most feasible way to test the function. Specifically the 
evaluator considers: 

a) the approach that will be used, for instance, whether the security function will be tested at an external 
interface, at an internal interface using a test harness, or will an alternate test approach be employed (e.g. 
in exceptional circumstances, a code inspection); 

b) the security function interface(s) that will be used to stimulate the security function and observe 
responses; 

c) the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need 
to exist and security attributes they will need to have); 

d) special test equipment that will be required to either stimulate a security function (e.g. packet generators) 
or make observations of a security function (e.g. network analysers). 

The evaluator may find it practical to test each security function using a series of test cases, where each test 
case will test a very specific aspect of expected behaviour. 

The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant 
design specification, and to the ST, if necessary. 

1 3.9.5.4.3 Work unit 4:ATEJND.2-6 

The evaluator shall conduct testing 

The evaluator uses the test documentation developed as a basis for executing tests on the TOE. Thu test 
documentation is used as a basis for testing but this does not preclude the evaluator from performing 
additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered 
during testing. These new tests are recorded in the test documentation. 

13.9.5.4.4 Workunit4:ATEJND.2-7 

The evaluator shall record the following information about the tests that compose the test subset: 

a) identification of the security function behaviour to belested; 

b) instructions to connect and setup all required test equipment as required to conduct the test; 

c) instructions to establish all prerequisite test conditions; 

d) instructions to stimulate the security function; 

e) instructions for observing the behaviour of the security function; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE; 

h) actual test results. 

The level of detail should be such that another evaluator could repeat the tests and obtain an equivalent result. 
While some specific details of the test results may be different (e.g. time and date fields in an audit record) the 
overall result should be identical. 

Tlrere may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. 
the actual test results of a test may not require any analysis before a comparison between the expected 
results can be made). The determination to omit this information is left to the evaluator, as Is the justification. 
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13.9.5.4.5 Work unit 4:ATEJND.2-8 

The evaluator shall check that all actual test results are consistent with the expected test results 

Any differences in the actual and expected test results may indicate that the TOE does not perform as 
specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require 
corrective maintenance to the TOE or test documentation and perhaps require re-running of impacted tests 
and modifying the test sample size and composition. This determination is left to the evaluator, as is its 
justification. 

13.9.5.5 Action ATEJND.2.3E 

13.9.5.5.1 Work unit 4:ATEJND.2-9 

The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures 

The overall aim of this work unit is to perform a sufficient number of the developer tests to confirm the validity 
of the developer's test results; The evaluator has to decide on the size of the sample, and the developer tests 
that will compose the sample. 

Taking into consideration the overall evaluator effort for the entire tests activity, normally 20% of the 
developer's tests should be performed although this may vary according to the nature of the TOE, and the test 
evidence supplied. 

All the developer tests can be traced back to specific security function(s). Therefore, the factors to consider in 
the selection of the tests to compose the sample are similar to those listed for subset selection in work-unit 
ATE_IND.2-4. Additionally, the evaluator may wish to employ a random sampling method to select developer 
tests to include in the sample. 

For guidance on sampling see A.2, Sampling. 

1 3.9.5.5.2 Work unit 4: ATE JND.2-1 

The evaluator shall check that all the actual test results are consistent with the expected test results 

Inconsistencies between the developer's expected test results and actual test results will compel the evaluator 
to resolve the discrepancies. Inconsistencies encountered by the evaluator could be resolved by a valid 
explanation and resolution of the inconsistencies by the developer. 

If a satisfactory explanation or resolution can not be reached, the evaluator's confidence in the developer's 
test results may be lessened and it may even be necessary for the evaluator to increase the sample size, to 
regain confidence in the developer testing. If the increase in sample size does not satisfy the evaluator's 
concerns, it may be necessary to repeat the entire set of developer's tests. Ultimately, to the extent that the 
TSF subset identified in work unit ATEJND.2-4 is adequately tested, deficiencies with the developer's tests 
need to result in either corrective action to the developer's tests or in the production of new tests by the 
evaluator. 

13.9.5.5.3 Work unit 4:ATEJND.2-11 

The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, 
depth and results 

The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing 
approach and effort expended on the testing activity during the evaluation. The intent of providing this 
information is to give a meaningful overview of the testing effort. It is not intended that the information 
regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. 
The intention is to provide enough detail to allow other evaluators and overseers to gain some insight about 
the testing approach chosen, amount of evaluator testing performed, amount of developer tests performed, 
TOE test configurations, and the overall results of the testing activity. 
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Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: 

a) TOE test configurations. The particular configurations of the TOE that were tested. 

b) subset size chosen. The amount of security functions that were tested during the evaluation and a 
justification for the size. 

c) selection criteria for the security functions that compose the subset. Brief statements about the factors 
considered when selecting security functions for inclusion in the subset. 

d) security functions tested. A brief listing of the security functions that merited inclusion in the subset. 

e) developer tests performed. The amount of developer tests performed and a brief description of the criteria 
used to select the tests. 

f) verdict for the activity. The overall judgement on the results of testing during the evaluation. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the testing the evaluator performed during the evaluation. 

13.10 Vulnerability assessment activity 

The purpose of the vulnerability assessment activity is to determine the existence and exploitability of flaws or 
weaknesses in the TOE in the intended environment. This determination is based upon analysis performed by 
the developer and the evaluator, and is supported by evaluator testing. 

1 3.10.1 Evaluation of Misuse (AVA_MSU.2) 

13.10.1.1 Objectives 

The objectives of this sub-activity are to determine whether the guidance is misleading, unreasonable or 
conflicting, whether secure procedures for all modes of operation have been addressed, and whether use of 
the guidance will facilitate prevention and detection of insecure TOE states. 

13.10.1.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the low-level design; 

e) the subset of the implementation representation; 

f) the TOE security policy model; 

g) the user guidance; 

h) the administrator guidance; 

i) the secure installation, generation, and start-up procedures; 

j) the misuse analysis of the guidance; 

k) the test documentation; 
I) the TOE suitable for testing. 



232 



IS 15671 :2006 
ISO/IEC 18045: 2005 

13.10.1.3 Application notes 

The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and 
the secure installation, generation, and start-up procedures. Installation, generation, and start-up procedures 
here refers to all procedures the administrator Is responsible to perform to progress the TOE from a delivered 
state to an operational state. 

Thist:omponent includes a requirement for developer analysis that is not present in AVA_MSU.1 Examination 
of guidance. Validation of this analysis should not be used as a substitute for the evaluator's own examination 
of the guidance documentation, but should be used to provide evidence that the developer has also explicitly 
addressed the issue of misuse. 

13.10.1.4 Action AVA_MSU.2.1E 

13.10.1.4.1 Work unit 4:AVA_MSU.2-1 

ISO/IEC 15408-3 AVA_MSU.2.1C: The guidance documentation shall identify all possible modes of operation 
of the TOE (including operation following failure or operational error), their consequences and implications for 
maintaining secure operation. 

The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance 
identifies all possible modes of operation of the TOE (including, if applicable, operation following failure or 
operational error), their consequences and implications for maintaining secure operation. 

Other evaluation evidence, particularly the functional specification and test documentation, provide an 
information source that the evaluator should use to determine that the guidance contains sufficient guidance 
information. 

The evaluator should focus on a single security function at a time, comparing the guidance for securely using 
the security function with other evaluation evidence, to determine that the guidance related to the security 
function is sufficient for the secure usage (i.e consistent with the TSP) of that security function. The evaluator 
should also consider the relationships between functions, searching for potential conflicts. 

13.10.1.4.2 Work unit 4:AVA_MSU.2-2 

ISO/IEC 15408-3 AVA_MSU.2.2C: The guidance documentation shall be complete, clear, consistent and 
reasonable. 

The evaluator shall examine the guidance to determine that it is clear and internally consistent. 

The guidance is unclear if it can reasonably be misconstrued by an administrator or user, and used in a way 
detrimental to the TOE, or to the security provided by the TOE. 

For guidance on consistency analysis see A. 3, Consistency analysis. 

13.10.1.4.3 Work unit4:AVA_MSU.2-3 

The evaluator shall examine the guidance and other evaluation evidence to determine that the guidance is 
complete and reasonable. 

The evaluator should apply familiarity with the TOE gained from performing other evaluation activities to 
determine that the guidance is complete. 

In particular, the evaluator should consider the functional specification and TOE summary specification. All 
security functions described in these documents should be described in the guidance as required to permit 
their secure administration and use. The evaluator may, as an aid, prepare an informal mapping between the 
guidance and these documents. Any omissions in this mapping may indicate incompleteness. 
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The guidance is unreasonable if it makes demands on the TOE's usage or operational environment that are 
inconsistent with the ST or unduly onerous to maintain security. 

The evaluator should note that results gained during the performance of work units from the AGD_ADM sub- 
activity will provide useful input to this examination. 

13.10.1.4.4 Work unit 4:AVA_MSU.2-4 

ISO/lEC 15408-3 AVA_MSU.2.3C: The guidance documentation stiall list all assumptions about the intended 
environment. 

The evaiuator shall examine the guidance to determine that all assumptions about the intended environment 
are articulated. 

The evaluator analyses the assumptions about the intended TOE security environment of the ST and 
compares them with the guidance to ensure that all assumptions about the intended TOE security 
environment of the ST that are relevant to the administrator or user are described appropriately in the 
guidance. 

13.10.1.4.5 Work unit4:AVA_MSU.2-5 

ISO/lEC 15408-3 AVA_MSU.2.4C: The guidance documentation shall list all requirements for external security 
measures (including external procedural, physical and personnel controls). 

The evaluator shall examine the guidance to determine that all requirements for external security measures 
are articulated. 

The evaluator analyses the guidance to ensure that it lists all external procedural, physical, personnel and 
connectivity controls. The security objectives in the ST for the non-IT environment will indicate what is 
required. 

13.10.1.4.6 Work umt4:AVA_MSU.2-6 

ISO/lEC 15408-3 AVA_MSU.2.5C: The analysis documentation shall demonstrate that the guidance 
documentation is complete. 

The evaluator shall examine the developer's analysis to determine that the developer has taken adequate 
measures to ensure that the guidance is complete. 

The developer analysis may comprise mappings from the ST or the functional specification to the guidance in 
order to demonstrate that the guidance Is complete. Whatever evidence is provided by the developer to 
demonstrate completeness, the evaluator should assess the developer's analysis against any deficiencies 
found during the conduct of work units AVA_MSU.2-1 through AVA_MSU.2-5, and AVA_MSU.2-7. 

13.10.1.5 Action AVA_MSU.2.2E 

13.10.1.5.1 Work unit 4:AVA_MSU.2-7 

The evaluator shall perform ail administrator and user (if applicable) procedures necessary to configure and 
install the TOE to determine that the TOE can be configured and used securely using only the supplied 
guidance. 

Configuration and installation requires the evaluator to advance the TOE from a deliverable state to the state 
in which it is operational and enforcing a TSP consistent with the security objectives specified in the ST. 

The evaluator should follow only the developer's procedures as documented in the user and administrator 
guidance that is normally supplied to the consumer of the TOE. Any difficulties encountered during such an 
exercise may be indicative of incomplete, unclear, inconsistent or unreasonable guidance. 
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Note that work performed to satisfy this work unit may also contribute towards satisfying evaluator action 
AD0JGS.1.2E. 

13.10.1.5.2 Work unit 4:AVA,MSU.2-8 

The evaluator shall perform other security relevant procedures specified in the guidance to determine that the 
TOE can be configured and used securely using only supplied guidance. 

The evaluator should follow only the developer's procedures as documented in the user and administrator 
guidance that is normally supplied to the consumer of the TOE. 

The evaluator should employ sampling in carrying out this work unit. When choosing a sample the evaluator 
should consider: 

a) the clarity of the guidance - any potential unclear guidance should be included in the sample; 

b) guidance that will be used most often - infrequently used guidance should not normally be included in the 
sample; 

c) complexity of the guidance - complex guidance should be included in the sample; 

d) severity of error - procedures for which error imparts the greatest severity on security should be included 
in the sample; 

e) the nature of the TOE - the guidance related to the normal or most likely use of the TOE should be 
included in the sample. 

For guidance on sampling see A.2, Sampling 

13.10.1.6 Action AVA_MS0.2.3E 

13.10.1.6.1 Work unit 4:AVA_MSU.2-9 

The evaluator shall examine the guidance to determine that sufficient guidance is provided for the consumer 
to effectively administer and use the TOE's security functions, and to detect insecure states. 

TOEs may use a variety of ways to assist the consumer in effectively using the TOE securely. One TOE may 
employ functionality (features) to alert the consumer when the TOE is in an insecure state, whilst other TOEs 
may be delivered with enhanced guidance containing suggestions, hints, procedures, etc. on using the 
existing security features most effectively; for instance, guidance on using the audit feature as an aid for 
detecting insecure states. 

To arrive at a verdict for this work unit, the evaluator considers the TOE's functionality, its purpose and 
intended environment, and assumptions about its usage or users. The evaluator should arrive at the 
conclusion that, if the TOE can transition into an insecure state, there is reasonable expectation that use of 
the guidance would permit the insecure state to be detected in a timely manner. The potential for the TOE to 
enter into insecure states may be determined using the evaluation deliverables, such as the ST, the functional 
specification and the high-level design of the TSF. 

13.10.1.7 Action AVA_MSU.2.4E 

13.10.1.7.1 Work unit4:AVA_MSU.2-10 

The evaluator shall examine the developer's analysis of the guidance to determine that guidance is provided 
for secure operation in all modes of operation of the TOE. 

The results of evaluation action AVA_MSU.2.1E should provide a basis with which to evaluate the developer's 
analysis. Having evaluated the potential for misuse of the guidance, the evaluator should be able to determine 
that the developer's misuse analysis meets the objectives of this sub-activity. 
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13.10.2 Evaluation of Strength of TOE security functions (AVA_S0F.1) 

13.10.2.1 Objectives 

The objectives of this sub-activity are to determine whether SOF claims are made in the ST for all probabilistic 
or permutationai mechanisms and whether the developer's SOF claims made in the ST are supported by an 
analysis that is correct. 

13.10.2.2 input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 

c) the high-level design; 

d) the low-level design; 

e) the subset of the implementation representation; 

f) the user guidance: 

g) the administrator guidance; 

h) the strength of TOE security functions analysis. 

13.10.2.3 Application notes 

SOF analysis is performed on mechanisms that are probabilistic or permutationai in nature, such as password 
mechanisms or biometrics. Although ^cryptographic mechanisms are also probabilistic in nature and are often 
described in terms of strength, AVA_S0F.1 Strength of TOE security function evaluation is not applicable to 
cryptographic mechanisms. For such mechanisms, the evaluator should seek scheme guidance. 

Although SOF analysis is performed on the basis of individual mechanisms, the overall determination of SOF 
is based on functions. Where more than one probabilistic or permutationai mechanism is employed to provide 
a security function, each distinct mechanism must be analysed. The manner in which these mechanisms 
combine to provide a security function will determine the overall SOF level for that function. The evaluator 
needs design information to understand how the mechanisms work together to provide a function, and a 
minimum level for such information is given by the dependency on ADV_HLD.1 Descriptive high-level design. 
The actual design information available to the evaluator is determined by the EAL, and the available 
information should be used to support the evaluator's analysis when required. 

For a discussion on SOF in relation to multiple TOE domains see subclause Evaluation of IT security 
requirements (ASE_REQ.1). 

13.10.2.4 Action AVA_SOF.1. IE 

13.10.2.4.1 Work unit 4: AVA_S0F.1-1 

ISO/IEC 15408-3 AVA_S0F.1.1C: For each mechanism with a strength of TOE security function claim the 
strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level 
defined in the PP/ST. 

The evaluator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim in the ST expressed as a SOF rating. 
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If SOF claims are expressed solely as SOF metrics, then this work unit is not applicable and is therefore 
considered to be satisfied. 

A SOF rating is expressed as one of SOF-basic, SOF-medium or SOF-high, which are defined in terms of 
atfacl< potential - refer to tSO/lEC 15408-1 clause 2. A minimum overall SOF requirement expressed as a 
rating applies to all non-cryptographic, probabilistic or permutational security mechanisms. However, 
individual mechanisms may have a SOF claim expressed as a rating that exceeds the overall SOF 
requirement. 

Guidance on determining the attack potential necessary to effect an attack and, hence, to determine SOF as a 
rating is in A.8, Strength of function and vulnerability analysis. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

13.10.2.4.2 Work unit 4:AVA_SOF.1.2 

ISO/IEC 15408-3 AVA_S0F.1 .20: For each mechanism with a specific strength of TOE security function claim 
the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of 
function metric defined in the PP/ST 

The evaiuator shall check that the developer has provided a SOF analysis for each security mechanism for 
which there is a SOF claim in the ST expressed as a metric. 

If SOF claims are expressed solely as SOF ratings, then this work unit is not applicable and is therefore 
considered to be satisfied. 

A minimum overall SOF requirement expressed as a rating applies to all non-cryptographic, probabilistic or 
permutational mechanisms. However, individual mechanisms may have a SOF claim expressed as a metric 
that meets or exceeds the overall SOF requirement. 

The SOF analysis comprises a rationale justifying the SOF claim made in the ST. 

13.10.2.4.3 Work unit4:AVA_SOF.1-3 

The evaiuator shall examine the SOF analysis to determine that any assertions or assumptions supporting the 
analysis are valid. 

For example, it may be a flawed assumption that a particular implementation of a pseudo-random number 
generator will possess the required entropy necessary to seed the security mechanism to which the SOF 
analysis is relevant. 

Assumptions supporting the SOF analysis should reflect the worst case, unless worst case is invalidated by 
the ST. Where a number of different possible scenarios exist, and these are dependent on the behaviour of 
the human user or attacker, the case that represents the lowest strength should be assumed unless, as 
previously stated, this case is invalid. 

For example, a strength claim based upon a maximum theoretical password space (i.e. all printable ASCII 
characters) would not be worst case because it is human behaviour to use natural language passwords, 
effectively reducing the password space and associated strength. However, such an assumption could be 
appropriate if the TOE used IT measures, identified in the ST, such as password filters to minimise the use of 
natural language passwords. 

13.10.2.4.4 Workunit4:AVA_SOF.1-4 

The evaiuator shall examine the SOF analysis to determine that any algorithms, principles, properties and 
calculations supporting the analysis are correct. 

The nature of this work unit is highly dependent upon the type of mechanism being considered. A.8, Strength 
of function and vulnerability analysis, provides an example SOF analysis for an identification and 
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authentication function that is implemented using a password mechanism; the analysis considers the 
maximum password space to ultimately arrive at a SOF rating. For biometrics, the analysis should considei 
resolution and other factors impacting the mechanism's susceptibility to spoofing. 

SOF expressed as a rating is based on the minimum attack potential required to defeat the security 
mechanism. The SOF ratings are defined in terms of attack potential in ISO/IEC 15408-1 clause 2. 

For guidance on attack potential see A.8, Strength of function and vulnerability analysis. 

13.10.2.4.5 Work unit 4:AVA_SOF.1-5 

The evaluator shall examine the SOF analysis to determine that each SOF claim is met or exceeded. 
For guidance on the rating of SOF claims see A.8, Strength of function and vulnerability analysis. 

13.10.2.4.6 Work unit 4: AVA_SOF.1 -6 

The evaluator shall examine the SOF analysis to determine that all functions with a SOF claim meet the 
minimum strength level defined in the ST. 

13.10.2.5 Action AVA_S0F.1.2E 

13.10.2.5.1 Work unit 4: AVA_S0F.1 -7 

The evaluator shall examine the functional specification, the high-level design, the low-level design, the user 
guidance and the administrator guidance to determine that all probabilistic or permutational mechanisms have 
a SOF claim. 

The identification by the developer of security functions that are realised by probabilistic or pennutational 
mechanisms is verified during the ST evaluation. However, because the TOE summary specification may 
have been the only evidence available upon which to perform that activity, the identification of such 
mechanisms may be incomplete. Additional evaluation evidence required as input to this sub-activity may 
identify additional probabilistic or permutational mechanisms not already identified in the ST. If so, the ST will 
have to be updated appropriately to reflect the additional SOF claims and the developer will need to provide 
additional analysis that justifies the claims as input to evaluator action AVA_SOF.1 .1E. 

13.10.2.5.2 Work unit4:AVA_SOF.1-8 

The evaluator shall examine the SOF claims to determine that they are correct. 

Where the SOF analysis includes assertions or assumptions (e.g. about how many authentication attempts 
are possible per minute), the evaluator should independently confirm that these are correct. This may be 
achieved through testing or through independent analysis. 

13.10.3 Evaluation of Vulnerability analysis (AVA_VLA.2) 

13.10.3.1 Objectives 

The objective of this sub-activity is to determine whether the TOE, in its intended environment, has 
vulnerabilities exploitable by attackers possessing low attack potential. 

13.10.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the ST; 

b) the functional specification; 
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c) the high-level design; 

d) the low-level design; 

e) the subset of the implementation representation; 

f) the TOE security policy model; 

g) the user guidance; 

h) the administrator guidance; 

i) the secure installation, generation, and start-up procedures; 

j) the vulnerability analysis; 

k) the strength of function claims analysis; 

I) the TOE suitable for testing. 

Other input for this sub-activity is: 

a) current information regarding obvious vulnerabilities (e.g. from an overseer). 

13.10.3.3 Application notes 

The use of the term guidance in this sub-activity refers to the user guidance, the administrator guidance, and 
the secure installation, generation, and start-up procedures. 

The consideration of exploitable vulnerabilities will be determined by the security objectives and functional 
requirements in the ST. For example, if measures to prevent bypass of the security functions are not required 
in the ST (TSF physical protection (FPT_PHP), Reference mediation (FPT_RVM) and Domain separation 
(FPT_SEP) are absent) then vulnerabilities based on bypass should not be considered. 

Vulnerabilities may be in the public domain, or not, and may require skill to exploit, or not. These two aspects 
are related, but are distinct. It should not be assumed that, simply because a vulnerability is in the public 
domain, it can be easily exploited. 

The following terms are used in the guidance with specific meaning: 

a) Vulnerability - a weakness in the TOE that can be used to violate a security policy in some environment; 

b) Vulnerability analysis - A systematic search for vulnerabilities in the TOE, and an assessment of those 
found to determine their relevance for the intended environment for the TOE; 

c) Obvious vulnerability - a vulnerability that is open to exploitation that requires a minimum of 
understanding of the TOE, technical sophistication and resources; 

d) Potential vulnerability - A vulnerability the existence of which is suspected (by virtue of a postulated attack 
path), but not confirmed, in the TOE; 

e) Exploitable vulnerability - A vulnerability that can be exploited in the intended environment for the TOE; 

Non-exploitable vulnerability - A vulnerability that cannot be exploited in the intended environment for the 
TOE; 

g) Residual vulnerability - A non-exploitable vulnerability that could be exploited by an attacker with greater 
attack potential than is anticipated in the intended environment for the TOE; 
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h) Penetration testing - Testing carried out to determine the exploitability of Identified TOE potential 
vulnerabilities in the intended environment for the TOE. 

13.10.3.4 Action AVA_VLA.2.1E 

13.10.3.4.1 Work unit 4:AVA_VLA.2-1 

ISO/IEC 15408-3 AVA_VLA.2.1C: The vulnerability analysis documentation shall describe the analysis of the 
TOE deliverables peiformed to search for v\/ays in which a user can violate the TSP. 

ISO/lEC 15408-3 AVA_VLA.2.2C: The vulnerability analysis documentation shall describe the disposition of 
identified vulnerabilities. 

ISO/IEC 15408-3 AVA_VLA.2.3C: The vulnerability analysis documentation shall show, for all identified 
vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. 

ISO/IEC 15408-3 AVA_VLA.2.4C: The vulnerability analysis documentation shall justify that the TOE, with the 
identified vulnerabilities, is resistant to obvious penetration attacks. 

The evaluator shall examine the developer's vulnerability analysis to determine that the search for 
vulnerabilities has considered all relevant information. 

The developer's vulnerability analysis should cover the developer's search for vulnerabilities in at least all 
evaluation deliverables and public domain information sources. 

Information in the public domain is highly dynamic. Therefore, it is possible that new vulnerabilities are 
reported in the public domain between the time the developer performs the vulnerability analysis and the time 
that the evaluation is completed. The point at which monitoring of the public domain information ceases is an 
evaluation authority issue; therefore guidance and agreement should be sought from the evaluation authority. 

13.10.3.4.2 Work unit 4:AVA_VLA.2-2 

The evaluator shall examine the developer's vulnerability analysis to determine that each identified 
vulnerability is described and that a rationale is given for why it is not exploitable in the intended environment 
for the TOE. 

A vulnerability is termed non-exploitable if one or more of the following conditions exist: 

a) security functions or measures in the (IT or non-IT) environment prevent exploitation of the vulnerability in 
the intended environment. For instance, restricting physical access to the TOE to authorised users only 
may effectively render a TOE's vulnerability to tampering unexploitable; 

b) the vulnerability is exploitable but only by attackers possessing moderate or high attack potential. For 
instance, a vulnerability of a distributed TOE to session hijack attacks requires an attack potential beyond 
that of low. However, such vulnerabilities are reported in the ETR as residual vulnerabilities; 

c) either the threat is not claimed to be countered or the violable organisational security policy is not claimed 
to be achieved by the ST. For instance, a firewall whose ST makes no availability policy claim and is 
vulnerable to TCP SYN attacks (an attack on^ common Internet protocol that renders hosts incapable of 
servicing connection requests) should not fail this evaluator action on the basis of this vulnerability alone. 

For guidance on determining attack potential necessary to exploit a vulnerability see A.8, Strength of function 
and vulnerability analysis. 

13.10.3.4.3 Work unit4:AVA_VLA.2-3 

The evaluator shall examine the developer's vulnerability analysis to determine that it is consistent with the ST 
and the guidance. 
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The developer's vulnerability analysis may address a vulnerability by suggesting specific configurations or 
settings for TOE functions. If such operating constraints are deemed to be effective and consistent with the ST, 
then all such configurations/settings should be adequately described in the guidance so that they may be 
employed by the consumer. 

13.10.3.5 Action AVA_VLA.2.2E 

13.10.3.5.1 Work unit 4:AVA_VLA.2-4 

The evaluator shall devise penetration tests, building on the developer vulnerability analysis. 
The evaluator prepares for penetration testing: 

a) as necessary to attempt to disprove the developer's analysis in cases where the developer's rationale for 
why a vulnerability is unexploitable is suspect in the opinion of the evaluator; 

b) as necessary to determine the susceptibility of the TOE, in its intended environment, to a vulnerability not 
considered by the developer. The evaluator should have access to current information (e.g. from the 
overseer) regarding obvious public domain vulnerabilities that may not have been considered by the 
developer, and may also have identified potential vulnerabilities as a result of performing other evaluation 
activities. 

The evaluator is not expected to test for vulnerabilities (including those in the public domain) beyond those for 
which a low attack potential is required to effect an attack. In many cases, however, it will be necessary to 
carry out a test before the attack potential required can be determined. Where, as a result of evaluation 
expertise, the evaluator discovers a vulnerability that is beyond low attack potential, this is reported in the ETR 
as a residual vulnerability. 

With an understanding of the suspected vulnerability, the evaluator determines the most feasible way to test 
for the TOE'S susceptibility. Specifically the evaluator considers: 

a) the security function interfaces that will be used to stimulate the TSF and observe responses; 

b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to 
exist and security attributes they will need to have); 

c) special test equipment that will be required to either stimulate a security function or make observations of 
a security function. 

The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where 
each test case will test for a specific vulnerability. 

13.10.3.5.2 Work unit4:AVA_VLA.2-5 

The evaluator shall produce penetration test documentation for the tests that build upon the developer 
vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall 
include; 

a) identification of the vulnerability the TOE is being tested for; 

b) instructions to connect and setup all required test equipment as required to conduct the penetration test; 

c) instructions to establish all penetration test prerequisite initial conditions; 

d) instructions to stimulate the TSF; 

e) instructions for observing the behaviour of the TSF; 
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f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE. 

The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the 
tests and obtain an equivalent result. 

13.10.3.5.3 Work unit 4:AVA_VLA.2-6 

The evaluator shall conduct penetration testing, building on the developer vulnerability analysis. 

The evaluator uses the penetration test documentation resulting from work unit AVA_VLA.2-4 as a basis for 
executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad 
hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learned 
during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test 
documentation. Such tests may be required to follow up unexpected results or observations, or to investigate 
potential vulnerabilities suggested to the evaluator during the pre-planned testing. 

13.10.3.5.4 Work unit 4:AVA_VLA.2-7 

The evaluator shall record the actual results of the penetration tests. 

While some specific details of the actual test results may be different from those expected (e.g. time and date 
fields in an audit record) the overall result should be identical. Any differences should be justified. 

13.10.3.5.5 Work unit 4:AVA_VLA.2-8 

The evaluator shall report in the ETR the evaluator penetration testing efforts, outlining the testing approach, 
configuration, depth and results. 

The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration 
testing approach and effort expended on this sub-activity. The intent of providing this information is to give a 
meaningful overview of the evaluator's penetration testing effort. It is not intended that the information 
regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual 
penetration tests. The intention is to provide enough detail to allow other evaluators and overseers to gain 
some insight about the penetration testing approach chosen, amount of penetration testing perfonnned, TOE 
test configurations, and the overall results of the penetration testing activity. 

information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts 
is: 

a) TOE test configurations. The particular configurations of the TOE that were penetration tested; 

b) security functions penetration tested. A brief listing of the security functions that were the focus of the 
penetration testing; 

c) verdict for the sub-activity. The overall judgement on the results of penetration testing. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the penetration testing the evaluator performed during the 
evaluation. 

13.10,3.6 Action AVA_VLA.2.3E 

13.10.3.6.1 Work unit 4:AVA_VLA.2-9 

The evaluator shall examine all inputs to this sub-activity to determine possible security vulnerabilities not 
already addressed by the developer's vulnerability analysis. 
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A flaw hypothesis methodology should be used whereby specifications and documentation for the TOE are 
analysed and then vulnerabilities in the TOE are hypothesised, or speculated. The list of hypothesised 
vulnerabilities is then prioritised on the basis of the estimated probability that a vulnerability exists and, 
assuming a vulnerability does exist, the attack potential required to exploit it, and on the extent of control or 
compromise it would provide. The prioritised list of potential vulnerabilities is used to direct penetration testing 
against the TOE. 

For guidance on determining attack potential necessary to exploit a vulnerability see A. 8. Strength of function 
and vulnerability analysis. 

Vulnerabilities hypothesised as exploitable only by attackers possessing moderate or high attack potential do 
not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be 
considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as 
residual vulnerabilities. 

Vulnerabilities hypothesised exploitable by an attacker possessing a low attack potential, that do not result in 
a violation of the security objectives specified in the ST, do not result in a failure of this evaluator action. 
Where analysis supports the hypothesis, these need not be considered further as an input to penetration 
testing. 

Vulnerabilities hypothesised as potentially exploitable by an attacker possessing a low attack potential and 
resulting in a violation of the security objectives should be the highest priority potential vulnerabilities 
comprising the list used to direct penetration testing against the TOE. 

Subject to the threats being present in the intended environment, the evaluator's independent vulnerability 
analysis should consider generic vulnerabilities under each of the following headings: 

a) generic vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the overseer; 

b) bypassing; 

c) tampering; 

d) direct attacks; 

e) misuse. 

Items b) - d) are now explained in greater detail. 

13.10.3.6.1.1 Bypassing 

Bypassing includes any means by which an attacker could avoid security enforcement, by: 

a) exploiting the capabilities of interfaces to the TOE, or of utilities which can interact with the TOE; 

b) inheriting privileges or other capabilities that should otherwise be denied; 

c) (where confidentiality is a concern) reading sensitive data stored or copied to inadequately protected 
areas. 

Each of the following should be considered {where relevant) in the evaluator's independent vulnerability 
analysis. 

a) Attacks based on exploiting the capabilities of interfaces or utilities generally take advantage of the 
absence of the required security enforcement on those interfaces. For example, gaining access to 
functionality that is implemented at a lower level than that at which access control is enforced. Relevant 
items include: 

1) changing the predefined sequence of invocation of functions; 
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2) executing an additional function; 

3) using a component in an unexpected context or for an unexpected purpose; 

4) using implementation detail introduced in less abstract representations; 

5) using the delay between time of access check and time of use. 

b) Changing the predefined sequence of invocation of components should be considered where there is an 
expected order in which interfaces to the TOE (e.g. user commands) are called to perform some security 
function (e.g. opening a file for access and then reading data from it). If a security function is invoked on 
one of the TOE interfaces (e.g. an access control check), the evaluator should consider whether it is 
possible to bypass the security function by performing the call at a later point in the sequence or by 
missing it out altogether. 

c) Executing an additional component (in the predefined sequence) is a similar form of attack to the one just 
described, but involves the calling of some other TOE interface at some point in the sequence. It can also 
involve attacks based on interception of sensitive data passed over a network by use of network traffic 
arralysers (the additional component here being the network traffic analyser). 

d) Using a component in an unexpected context or for an unexpected purpose includes using an unrelated 
TOE interface to bypass a security function by using it to achieve a purpose that it was not designed or 
intended to achieve. Covert chann^els are an example of this type of attack. The use of undocumented 
interfaces (which may be insecure) also falls into this category (these include undocumented support and 
help facilities). 

e) Using implementation detail introduced in lower representations again includes the use of covert channels 
in which an attacker takes advantage of additional functions, resources or attributes that are introduced to 
the TOE as a consequence of the refinement process (e.g. use of a lock variable as a covert channel). 
Additional functionality may also include test harness code contained in software modules. 

f) Using the delay between time of check and time of use includes scenarios where an access control check 
is made and access granted, and an attacker is subsequently able'to create conditions in which, had they 
applied at the time the access check was made, would have caused the check to fail. An example would 
be a user creating a background process to read and send highly sensitive data to the user's terminal, 
and then logging out and logging back in again at a lower sensitivity level. If the background process is 
not terminated when the user logs off, the MAC checks would have been effectively bypassed. 

g) Attacks based on inheriting privileges are generally based on illicitly acquiring the privileges or capabilities 
of some privileged component, usually by exiting from it in an uncontrolled or unexpected manner. 
Relevant items include: 

1) executing data not intended to be executable, or making it executable; 

2) generating unexpected input for a component; 

3) invalidating assumptions and properties on which lower-level components rely. 

h) Executing data not intended to be executable, or making it executable includes attacks involving viruses 
(e.g. putting executable code or commands in a file which are automatically executed when the file is 
edited or accessed, thus inheriting any privileges the owner of the file has). 

i) Generating unexpected input for a component can have unexpected effects which an attacker could take 
advantage of. For example, if the TOE is an application implementing security functions that could be 
bypassed if ^ user gains access to the underlying operating system, it may be possible to gain such 
access following the login sequence by exploring the effect of hitting various control or escape sequences 
whilst a password is being authenticated. 
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j) Invalidating assumptions and properties on which lower level components rely includes attacks based on 
breaking out of the constraints of an application to gain access to an underlying operating system in order 
to bypass the security functions implemented by the application. In this case the assumption being 
invalidated is that it is not possible for a user of the application to gain such access. A similar attack can 
be envisaged if secuhty functions are implemented by an application on an underlying database 
management system: again the security functions could be bypassed if an attacker can break out of the 
constraints of the application. 

k) Attacks based on reading sensitive data stored in inadequately protected areas (applicable where 
confidentiality is a concern) include the following issues which should be considered as possible means of 
gaining access to sensitive data: 

1) disk scavenging; 

2) access to unprotected memory; 

3) exploiting access to shared writable files or other shared resources (e.g. swap files); 

I) Activating error recovery to determine what access users can obtain. For example, after a crash an 
automatic file recovery system may employ a lost and found directory for headerless files, which are on 
disc without labels. If the TOE implements mandatory access controls, it is important to investigate at 
what security level this directory is kept (e.g. at system high), and who has access to this directory. 

13.10.3.6.1.2 Tampering 

Tampering includes any attack based on an attacker attempting to influence the behaviour of a security 
function or mechanism (i.e. corruption or de-activation), for example by: 

a) accessing data on whose confidentiality or integrity the security function or mechanism relies; 

b) forcing the TOE to cope with unusual or unexpected circumstances; 

c) disabling or delaying security enforcement. 

Each of the following should be considered (where relevant) in the evaluator's independent vulnerability 
analysis. 

a) Attacks based on accessing data on whose confidentiality or integrity the security function or mechanism 
include: 

1) reading, writing or modifying internal data directly or indirectly; 

2) using a component in an unexpected context or for an unexpected purpose; 

3) using interferences between components that are not visible at a higher level of abstraction. 

b) Reading, writing or modifying Internal data directly or indirectly includes the following types of attack 
which should be considered: 

1) reading "secrets" stored internally, such as user passwords; 

2) spoofing internal data that security enforcing mechanisms rely upon; 

3) modifying environment variables (e.g. logical names), or data in configuration files or temporary files. 

c) It may be possible to hoodwink a trusted process into modifying a protected file that it wouldn't normally 
access. 
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d) The evaluator should also consider the following "dangerous features": 

1) source code resident on theTOE along with a compiler (for instance, it may be possible to modify the ' 
login source code); 

2) an interactive debugger and patch facility (for instance, it may be possible to modify the executable 
image); 

3) the possibility of making changes at device controller level, where file protection does not exist; 

4) diagnostic code which exists in the source code and that may be optionally included; 

5) developer's tools left in the TOE. 

e) Using a component in an unexpected context or for an unexpected purpose includes (for example), where 
the TOE is an application built upon an operating system, users exploiting knowledge of a word processor 
package or other editor to modify their own command file (e.g. to acquire greater privileges). 

f) Using interference between components which are not visible at a higher level of abstraction includes 
attacks exploiting shared access to resources, where modification of a resource by one component can 
influence the behaviour of another (trusted) component, e.g. at source code level, through the use of 
global data or indirect mechanisms such as shared memory or semaphores. 

g) Attacks based on forcing the TOE to cope with unusual or unexpected circumstances should always be 
considered. Relevant items include: 

1) generating unexpected input for a component; 

2) invalidating assumptions and properties on which lower-level components rely. 

h) Generating unexpected input for a component includes investigating the behaviour of the TOE when: 

1) command input buffers overflow (possibly "crashing the stack" ovenwriting other storage, which an 
attacker may be able to take advantage of, or forcing a crash dump that may contain sensitive 
information such as clear-text passwords); 

2) invalid commands or parameters are entered (including supplying a read-only parameter to an 
interface which expects to return data via that parameter); 

3) an end-of-file marker (e.g. CTRL/Z or CTRL/D) or null character is inserted in an audit trail. 

i) Invalidating assumptions and properties on which lower-level components rely includes attacks taking 
advantage of errors in the source code where the code assumes (explicitly or implicitly) that security 
relevant data is in a particular format or has a particular range of values. In these cases the evaluator 
should determine whether they can invalidate such assumptions by causing the data to be in a different 
format or to have different values, and if so whether this could confer advantage to an attacker. 

j) The correct behaviour of the security functions may be dependent on assumptions that are invalidated 
under extreme circumstances where resource limits are reached or parameters reach their maximum 
value. The evaluator should consider (where practical) the behaviour of the TOE when these limits are 
reached, for example: 

1) changing dates (e.g. examining how the TOE behaves when a critical date threshold is passed); 

2) filling discs; 

3) exceeding the maximum number of users; 

4) filling the audit log; 

5) saturating security alarm queues at a console; 
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6) overloading various parts of a multi-user TOE which relies heavily upon communications 
components; 

7) swamping a network, or individual hosts, with traffic; 

8) filling buffers or fields. 

k) Attacks based on disabling or delaying security enforcement include the following items: 

1) using interrupts or scheduling functions to disrupt sequencing; 

2) disrupting -concurrence; 

3) using Interference between components which are not visible at a higher level of abstraction. 

1) Using interrupts or scheduling functions to disrupt sequencing includes investigating the behaviour of the 
TOE when: 

1) a command is interrupted (with CTRUC, CTRUY, etc.); 

2) a second interrupt is issued before the first is acknowledged. 

m) The effects of terminating security critical processes (e.g. an audit daemon) should be explored. Similarly, 
it may be possible to delay the logging of audit records or the issuing or receipt of alarms such that it is of 
no use to an administrator (since the attack may already have succeeded). 

n) Disrupting concurrence includes investigating the behaviour of the TOE when two or more subjects 
attempt simultaneous access. It may be that the TOE can cope with the interlocking required when two 
subjects attempt simultaneous access, but that the behaviour becomes less well defined in the presence 
of further subjects. For example, a critical security process could be put into a resource-wait state if two 
other processes are accessing a resource which it requires. 

o) Using interference between components which are not visible at a higher level of abstraction may provide 
a means of delaying a time-critical trusted process. 

13.10.3.6.1.3 Direct attacks 

Direct attack includes the identification of any penetration tests necessary to confirm or disprove the claimed 
minimum strength of functions. When identifying penetration tests under this heading, the evaluator should 
also be aware of the possibility of vulnerabilities existing as a result of security mechanisms being susceptible 
to direct attack. 

13.10.3.6.1.4 Misuse 

Misuse includes the identification of any penetration tests necessary to confirm or disprove the misuse 
analysis. Issues to be considered include: 

a) behaviour of the TOE when start-up, closedown or error recovery is activated; 

b) behaviour of the TOE under extreme circumstances (sometimes termed overload or asymptotic 
behaviour), particularly where this could lead to the de-activation or disabling of a security enforcing 
function or mechanism; 

c) any potential for unintentional misconfiguration or insecure use arising from attacks noted in the 
subclause on tampering above. 
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13.10.3.7 Action AVA_VLA.2.4E 

13.10.3.7.1 Work unit4:AVA„VLA.2-10 

The evaluator shall devise penetration tests, based on the independent vulnerability analysis. 

The evaluator prepares for penetration testing based on the prioritised list of vulnerabilities hypothesised in 
evaluator action AVA_VLA.2.3E. 

The evaluator Is not expected to test for vulnerabilities beyond those for which a low attack potential is 
required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a 
vulnerability that is exploitable only by an attacker with greater than low attack potential. Such vulnerabilities 
are to be reported In the ETR as residual vulnerabilities. 

With an understanding of the suspected vulnerability, the evaluator determines the most feasible way to test 
for the TOE'S suaceptibillty. Specifically the evaluator considers: 

a) the security function Interfaces that will be used to stimulate the TSF and observe responses; 

b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to 
exist and security attributes they will need to have); 

c) special test equipment that will be required to either stimulate a security function or make observations of 
a security function. 

The evaluator will probably find it practical to carry out penetration test using a series of test cases, where 
each test case will test for a specific vulnerability. 

13.10.3.7.2 Work unit 4:AVA_VLA.2-11 

The evaluator shall produce penetration test documentation for the tests based on the Independent 
vulnerability analysis, in sufficient detail to enable the tests to be repeatable. The test documentation shall 
include: 

a) Identification of the obvious vulnerability the TOE is being tested for; 

b) instructions to connect and setup all required test equipment as required to conduct the penetration test; 

c) instructions to establish all penetration test prerequisite initial conditions; 

d) instructions to stimulate the TSF; 

e) instructions for observing the behaviour of the TSF; 

f) descriptions of all expected results and the necessary analysis to be performed on the observed 
behaviour for comparison against expected results; 

g) instructions to conclude the test and establish the necessary post-test state for the TOE. 

The intent of specifying this level of detail in the test documentation Is to allow another evaluator to repeat the 
tests and obtain an equivalent result. 

13.10.3.7.3 Work untt4:AVA_VLA.2-12 

The evaluator shall conduct penetration testing, based on the independent vulnerability analysis. 

The evaluator uses the penetration test documentation resulting from work unit AVA_VLA.2-10 as a basis for 
executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad 
hoc penetration tests. If required, the evaluator may devise new tests as a result of information learned during 
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penetration testing that, If performed by the evaluator, are to be recorded in the penetration test 
documentation. Such tests may be required to follow up unexpected results or observations, or to investigate 
potential vulnerabilities suggested to the evaluator during the pre-planned testing. 

Should penetration testing show that a hypothesised vulnerability does not exist, then the evaluator should 
determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect 
or incomplete. 

13.10.3.7.4 Work unit4:AVA_VLA.2-13 

The evaluator shall record the actual results of the penetration tests. 

White some specific details of the actual test results may be different from those expected (e.g. time and date 
fields in an audit record) the overall result should be identical. Any differences should be justified. 

13.10.3.7.5 Work unit4:AVA_VLA.2-14 

The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, 
configuration, depth and results. 

The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration 
testing approach and effort expended on this sub-activity. The intent of providing this information is to give a 
meaningful overview of the evaluator's penetration testing effort. It is not intended that the information 
regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual 
penetration tests. The intention is to provide enough detail to allow other evaluators and overseers to gain 
some insight about tf^ penetration testing approach chosen, amount of penetration testing performed, TOE 
test configurations, and the overall results of the penetration testing activity. 

Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts 
is: 

a) TOE test configurations. The particular configurations of the TOE that were penetration tested; 

b) security functions penetration tested. A brief listing of the security functions that were the focus of the 
penetration testing; 

c) verdict for the sub-activity. The overall judgement on the results of penetration testing. 

This list is by no means exhaustive and is only intended to provide some context as to the type of information 
that should be present in the ETR concerning the penetration testing the evaluator performed during the 
evaluation. 

13.10.3.8 Action AVA_VLA.2.5E 

13.10.3.8.1 Work unit4:AVA_VLA.2-15 

The evaluator shall examine the results of all penetration testing and the conclusions of all vulnerability 
analysis to determine that the TOE, in its intended environment, is resistant to an attacker possessing a low 
attack potential. 

If the results reveal that the TOE, in its intended environment, has vulnerabilities exploitable by an attacker 
possessing less than a moderate attack potential, then this evaluator action fails. 

13.10.3.8.2 Work unit4:AVA_VLA.2-16 

The evaluator shall report in the ETR all exploitable vulnerabilities and residua! vulnerabilities, detailing for 
each: 

a) its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the 
evaluator, read in a publication); 
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b) the implicated security function(s), objective{s) not met, organisational security p.oltcy(ies) contravened 
and threat(s) realised; 

c) a description; 

d) whether it is exploitable in its intended environment or not (i.e. exploitable or residual); 

e) identification of evaluation party (e.g. developer, evaluator) who identified it. 

14 Flaw remediation sub-activities 

14.1 Evaluation of flaw remediation (ALC_FLR.1) 

14.1.1 Objectives 

The objective of this sub-activity is to determine whether the developer has established flaw remediation 
procedures that describe the tracking of security flaws, the identification of corrective actions, and the 
distribution of corrective action information to TOE users. 

14.1.2 input 

The evaluation evidence for this sub-activity is; 

a) the flaw remediation procedures documentation. 

14.1.3 Action ALC_FLR.1. IE 

14.1.3.1 Work unit ALC_FLR.1-1 

ISO/IEC 15408-3 ALC^FLR.1.1C: The flaw remediation procedures documentation stiall describe the 
procedures used to frac/( all reported security flaws in each release of the TOE. 

The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the 
procedures used to track all reported security flaws in each release of the TOE. 

The procedures describe the actions that are taken by the developer from the time each suspected security 
flaw is reported to the time that it is resolved. This includes the flaw's entire timeframe, from initial detection 
through ascertaining the flaw is a security flaw, to resolution of the security flaw. 

If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the Flaw remediation 
(ALC_FLR) requirements) for the flaw remediation procedures to track it further; only that there be an 
explanation of why the flaw is not security-relevant. 

While these requirements do not mandate that there be a publicised means for TOE users to report security 
flaws, they do mandate that all security flaws that are reported be tracked. That is, a reported security flaw 
cannot >6 ignored simply because it comes from outside the developer's organisation. 

14.1.3.2 WorkunitALC_FLR.1-2 

ISO/IEC 15408-3 ALC_FLR.1.2C: The flaw remediation procedures shall require that a description of the 
nature and effect of each security flaw be provided, as well as the status of finding a conrection to that flaw. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would produce a description of each security flaw in terms of its nature and effects. 
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The procedures identify the actions that are taken by the developer to describe the nature and effects of each 
security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw 
addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the 
implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF 
that are affected and how those portions are affected. For example, a security flaw in the implementation 
might be found that affects the identification and authentication enforced by the TSF. by permitting 
authentication with the password "BACKDOOR". 

14.1.3.3 Work unit ALC_FLR.1-3 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would identify the status of finding a correction to each security flaw. 

The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at 
least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to 
be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional 
stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security 
flaws for which a solution has been found but not yet implemented) be included. 

14.1 .3.4 Work unit ALC_FLR.1-4 

ISO/IEC 15408-3 ALC_FLR.1.3C: The flaw remediation procedures shall require that corrective actions be 
identified for each of the security flaws. 

The evaluator shall check the flaw remediation procedures to determine that the application of these 
procedures would identify the corrective action for each security flaw. 

Corrective action may consist of a repair to the hardware, firmware, or software portions of the TOE. a 
modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. 
details of procedural measures to be taken to obviate the security flaw) includes both those measures serving 
as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where 
it is determined that the procedural measure is the best solution). 

If the source of the security flaw is a documentation error, the corrective action consists of an update of the 
affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update 
made to the affected TOE guidance to reflect these corrective procedures. 

14.1.3.5 Work unit ALC_FLR.1-5 

ISO/IEC 15408-3 ALC_FLR.1.4C: The flaw remediation procedures documentation shall describe the 
methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. 

The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a 
means of providing the TOE users with the necessary information on each security flaw. 

The necessary information about each security flaw consists of its description (not necessarily at the same 
level of detail as that provided as part of work unit ALC_FLR.1-2), the prescribed corrective action, and any 
associated guidance on implementing the correction. 

TOE users may be provided such information, correction, and documentation updates in any of several ways, 
such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to 
install the correction. In cases where the means of providing this information requires action to be initiated by 
the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving 
the information. 

The only metric for assessing the adequacy of the method used for providing the information, corrections and 
guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, 
consider the method of dissemination where the requisite data is posted to a website for one month, and the 
TOE users know that this will happen and when this will happen. This may not be especially reasonable or 
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effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user could obtain the 
necessary information. On the other hand, if the information were posted to the website for only one hour, yet 
TOE users had no way of l^nowing this or when it would be posted, it is infeasible that they would ever get the 
necessary information. 

14.2 Evaluation of flaw remediation (ALC_FLR.2) 

14.2.1 Objectives 

The objective of this sub-activity is to determine whether the developer has established flaw remediation 
procedures that describe the tracking of security flaws, the identification of corrective actions, and the 
distribution of corrective action information to TOE users. Additionally, this sub-activity determines whether the 
developer's procedures provide for the corrections of security flaws, for the receipt of flaw reports from TOE 
users, and for assurance that the corrections introduce no new security flaws. 

In order for the developer to be able to act appropriately upon security flaw reports from TOE users, TOE 
users need to understand how to submit security flaw reports to the developer, and developers need to know 
how to receive these reports. Flaw remediation guidance addressed to the TOE user ensures that TOE users 
are aware of how to communicate with the developer; flaw remediation procedures describe the developer's 
role is such communication 

14.2.2 Input 

The evaluation evidence for this sub-activity is: 

a) the flaw remediation procedures documentation; 

b) flaw remediation guidance documentation. 

14.2.3 Action ALC_FLR.2.1E 

14.2.3.1 Work unit ALC_FLR.2-1 

ISO/IEC 15408-3 ALC_FLR.2.1C: The flaw remediation procedures documentation shall descnbe the 
procedures used to track all reported security flaws in each release of the TOE. 

The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the 
procedures used to track all reported security flaws in each release of the TOE. 

The procedures describe the actions that are taken by the developer from the time each suspected security 
flaw is reported to the time that it is resolved. This includes the flaw's entire timeframe, from initial detection 
through ascertaining the flaw is a security flaw, to resolution of the security flaw. 

If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the Flaw remediation 
(ALC_FLR) requirements) for the flaw remediation procedures to track it further; only that there be an 
explanation of why the flaw is not security-relevant. 

14.2.3.2 Work unit ALC_FLR.2-2 

ISO/IEC 15408-3 ALC_FLR.2.2C: The flaw remediation procedures shall require that a description of the 
nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would produce a description of each security flaw in terms of its nature and effects. 

The procedures identify the actions that are taken by the developer to describe the nature and effects of each 
security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw 
addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the 
implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF 
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that are affected and how those portions are affected. For example, a security flaw in the implementation 
might be found that affects the identification and authentication enforced by the TSF by permitting 
authentication with the password "BACKDOOR". 

14.2.3.3 Work unit ALC_FLR.2-3 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would identify the status of finding a correction to each security flaw. 

The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at 
least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to 
be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional 
stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security 
flaws for which a solution has been found but not yet implemented) be included. 

14.2.3.4 Work unit ALC_FLR.2-4 

ISO/IEC 15408-3 ALC_FLR.2.3C: The flaw remediation procedures shall require that corrective actions be 
identified for each of the security flaws. 

The evaluator shall check the flaw remediation procedures to determine ihat the application of these 
procedures would identify the corrective action for each security flaw. 

Corrective action may consist of a repair to the hardware, firmware, or software portions of the TOE, a 
modification of TOE guidance, ^or both. Corrective acfion that constitutes modifications to TOE guidance (e.g. 
details of procedural nf>easures to be taken to obviate the security flaw) includes both those measures serving 
as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where 
it is determined that the procedural measure is the best solution). 

If the source of the security flaw is a documentation error, the corrective action consists of an update of the 
affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update 
made to the affected TOE guidance to reflect these corrective procedures. 

14.2.3.5 Work unit ALC_FLR.2-5 

ISO/IEC 15408-3 ALC_FLR.2.4C: The flaw remediation procedures documentation shall describe the 
methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. 

The evaluator shall examine the flaw remediation procedures documentation to determine that It describes a 
means of providing the TOE users with the necessary informafion on each security flaw. 

The necessary information about each security flaw consists of its description (not necessarily at the same 
level of detail as that provided as part of work unit ALC_FLR.2-2), the prescribed correcfive action, and any 
associated guidance on implementing the correction. 

TOE users may be provided such information, correction, and documentation updates in any of several ways, 
such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to 
install the correction. In cases where the means of providing this information requires action to be initiated by 
the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving 
the information. 

The only metric for assessing the adequacy of the method used for providing the information, corrections and 
guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, 
consider the method of dissemination where the requisite data is posted to a website for one month, and the 
TOE users know that this will happen and when this will happen. This may not be especially reasonable or 
effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user could obtain the 
necessary information. On the other hand, if the information were posted to the website for only one hour, yet 
TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the 
necessary information. 
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14.2.3.6 Work unit ALC_FLR.2-6 

ISO/IEC 15408-3 ALC_FLR.2.5C: The flaw remediation procedures shall describe a means by which the 
developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. 

The evaluator shall examine the flaw remediation procedures to determine that they describe procedures for 
the developer to accept reports of security flaws or requests for corrections to such flaws. 

The procedures ensure that TOE users have a means by which they can communicate with the TOE 
developer. By having a means of contact with the developer, the user can report security flaws, enquire about 
the status of security flaws, or request corrections to flaws. This means of contact may be part of a more 
general contact facility for reporting non-security related problems. 

The use of these procedures is not restricted to TOE users; however, only the TOE users are actively supplied 
with the details of these procedures. Others who might have access to or familiarity with the TOE can use the 
same procedures to submit reports to the developer, who is then expected to process them. Any means of 
submitting reports to the developer, other than those identified by the developer, are beyond the scope of this 
work unit; reports generated by other means need not be addressed. 

14.2.3.7 Work unit ALC_FLR.2-7 

ISO/IEC 1 5408-3 ALC_FLR.2.6C: The procedures for processing reported security flaws shall ensure that any 
reported flaws are corrected and the correction issued to TOE users. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would help to ensure every reported flaw is corrected. 

The flaw remediation procedures cover not only those security flaws discovered and reported by developer 
personnel, but also those reported by TOE users. The procedures are sufficiently detailed so that they 
describe how it is ensured that each reported security flaw is corrected. The procedures contain reasonable 
steps that show progress leading to the eventual, inevitable resolution. 

The procedures describe the process that is taken from the point at which the suspected security flaw is 
determined to be a security flaw to the point at which it is resolved. 

14.2.3.8 Work unit ALC_FLR.2-8 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would help to ensure that the TOE users are issued corrective actions for each security flaw. 

The procedures describe the process that is taken from the point at which a security flaw is resolved to the 
point at which the corrective action is provided. The procedures for deliveririg corrective actions should be 
consistent with the security objectives; they need not necessarily be identical to the procedures used for 
delivering the TOE, as documented to meet ADO_DEL, if included in the assurance requirements. For 
example, if the hardware portion of a TOE were originally delivered by bonded courier, updates to hardware 
resulting from flaw remediation would likewise expected to be distributed by bonded courier. Updates 
unrelated to flaw remediation would follow the procedures set forth in the documentation meeting the Delivery 
(ADO_DEL) requirements. 

14.2.3.9 Work unit ALC_FLR.2-9 

ISO/IEC 15408-3 ALC_FLR.2.7C: The procedures for processing reported security flaws shall provide 
safeguards that any corrections to these security flaws do not introduce any new flaws. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would result in safeguards that the potential correction contains no adverse effects. 

Through analysis, testing, or a combination of the two, the developer may reduce the likelihood that adverse 
effects will be introduced when a security flaw is corrected. The evaluator assesses whether the procedures 
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provide detail in how the necessary mix of analysis and testing actions is to be determined for a given 
correction. 

The evaluator also determines that, for instances where the source of the security flaw is a documentation 
problem, the procedures include the means of safeguarding against the Introduction of contradictions with 
other documentation. 

14.2.3.10 Work unit ALC_FLR.2-10 

ISO/IEC 15408-3 ALC_FLR.2.8C: The flaw remediation guidance shall describe a means by which TOE users 
report to ths.de¥6k^iai: any^spected security Haws in the TOE. 

The evaluator shall examine the flaw remediation guidance to determine that the application of these 
procedures would result in a means for the TOE user to provide reports of suspected security flaws or 
requests for corrections to such flaws. 

The guidance ensures that TOE users have a means by which they can communicate with the TOE developer. 
By having a means of contact with the developer, the user can report security flaws, enquire about the status 
of security flaws, or request corrections to flaws. 

14.3 Evaluation of flaw remediation (ALC_FLR.3) 

14.3.1 Objectives 

The objective of this sub-activity is to determine whether the developer has established flaw remediation 
procedures that describe the tracking of security flaws, the identification of corrective actions, and the 
distribution of corrective action information to TOE users. Additionally, this sub-activity determines whether the 
developer's procedures provide for the corrections of security flaws, for the receipt of flaw reports from TOE 
users, for assurance that the corrections introduce no new security flaws, for the establishment of a point of 
contact for each TOE user, and for the timely issue of corrective actions to TOE users. 

In order for the developer to be able to act appropriately upon security flaw reports from TOE users, TOE 
users need to understand how to submit security flaw reports to the developer, and developers need to know 
how to receive these reports. Flaw remediation guidance addressed to the TOE user ensures that TOE users 
are aware of how to communicate with the developer; flaw remediation procedures describe the developer's 
role is such communication. 

14.3.2 Input 

The evaluation evidence for this sub-activity is: 

a) the flaw remediation procedures documentation; 

b) flaw remediation guidance documentation. 

14.3.3 Action ALC_FLR.3 IE 

14.3.3.1 Work unit ALC_FLR.3-1 

ISO/IEC 15408-3 ALC_FLR.3.1C: The flaw remediation procedures documentation shall describe the 
procedures used to track all reported security flaws in each release of the TOE. 

The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the 
procedures used to track all reported security flaws in each release ot the TOE. 

The procedures describe the actions that are taken by the developer from the time each suspected security 
flaw is reported to the time that it is resolved. Thie includes the flaw's entire timeframe, from initial detection 
through ascertaining the flaw is a security flaw, to resolution of the security flaw. 
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If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the Flaw remediation 
(ALC_FLR) requirements) for the flaw remediation procedures to track it further; only that there be an 
explanation of why the flaw is not security-relevant. 

14.3.3.2 Work unit ALC_FLR.3-2 

ISO/IEC 15408-3 ALC_FLR.3.2C: The flaw remediation procedures shall require that a description of the 
nature and effect of each security flaw be provided, as well as the status of finding a con-ection to that flaw. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would produce a description of each security flaw in terms of its nature and effects. 

The procedures identify the actions that are taken by the developer to describe the nature and effects of each 
security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw 
addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the 
implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF 
that are affected and how those portions are affected. For example, a security flaw in ihe implementation 
might be found that affects the identification and authentication enforced by the TSF by permitting 
authentication with the password "BACKDOOR". 

14.3.3.3 Work unit ALC^FLR.3.3 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would identify the status of finding a correction to each security flaw. 

The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at 
ieast: suspected security flaws that have been reported, suspected security flaws that have been confirmed to 
be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional 
stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security 
flaws for which a solution has been found but not yet implemented) be Included. 

14.3.3.4 Work unit ALC_FLR.3-4 

ISO/IEC 15408-3 ALC_FLR.3.3C: The flaw remediation procedures shall require that corrective actions be 
identifled for each of the security flaws. 

The evaluator shall check the flaw remediation procedures to determine that the application of these 
procedures would identify the corrective action for each security flaw. 

CorrecfiVe action may consist of a repair to the hardware, firmware, or software portions of the TOE. a 
modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. 
details of procedural measures to be taken to obviate the security flaw) includes both those measures serving 
as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where 
it is determined that the procedural measure is the best solution). 

If the source of the security flaw Is a documentation error, the corrective action consists of an update of the 
affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update 
made to the affected TOE guidance to reflect these corrective procedures. 

14.3.3.5 Work unit ALC_FLR.3-5 

ISO/iEC 15408-3 ALC_FLR.3.4C: The flaw remediation procedures documentation shall describe the 
methods used to provide flaw infonnation, corrections andguidance on corrective actions to TOE users. 

The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a 
means of providing the TOE users with the necessary information on each security flaw. 
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The necessary information about each security flaw consists of its description (not necessarily at the same 
level of detail as that provided as part of work unit ALC_FLR.3-2), the prescribed corrective action, and any 
associated guidance on implementing the correction. 

TOE users may be provided such information, correction, and documentation updates in any of several ways, 
such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to 
install the correction. In cases where the means of providing this information requires action to be initiated by 
the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving 
the information. 

The only metric for assessing the adequacy of the method used for providing the information, corrections and 
guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, 
consider the method of dissemination where the requisite data is posted to a website for one month, and the 
TOE users know that this will happen and when this will happen. This may not be especially reasonable or 
effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user could obtain the 
necessary information. On the other hand, if the information were posted to the website for only one hour, yet 
TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the 
necessary information. 

For TOE users who register with the developer (see work unit ALC_FLR.3-12), the passive availability of this 
information is not sufficient. Developers must actively send the information (or a notification of its availability) 
to registered TOE users. 

14.3.3.6 Work unit ALC_FLR.3-6 

ISO/IEC 15408-3 AL9_FLR.3.5C: The flaw remediation procedures shall describe a means by which the 
developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would result in a means for the developer to receive from TOE user reports of suspected security 
flaws or requests for corrections to such flaws. 

The procedures ensure that TOE users have a means by which they can communicate with the TOE 
developer. By having a means of contact with the developer, the user can report security flaws, enquire about 
the status of security flaws, or request corrections to flaws. This means of contact may be part of a more 
general contact facility for reporting non-security related problems. 

The use of these procedures is not restricted to TOE users; however, only the TOE users are actively supplied 
with the details of these procedures. Others who might have access to or familiarity with the TOE can use the 
same procedures to submit reports to the developer, who is then expected to process them. Any means of 
submitting reports to the developer, other than those identified by the developer, are beyond the scope of this 
work unit; reports generated by other means need not be addressed. 

14.3.3.7 Work unit ALC_FLR.3-7 

ISO/IEC 15408-3 ALC_FLR.3.6C: The procedures for processing reported security flaws shall ensure that any 
reported flaws are corrected and the correction issued to TOE users. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would help to ensure that every reported flaw is corrected. 

The flaw remediation procedures cover not only those security flaws discovered and reported by developer 
personnel, but also those reported by TOE users. The procedures are sufficiently detailed so that they 
describe how it is ensured that each reported security flaw is corrected. The procedures contain reasonable 
steps that show progress leading to the eventual, inevitable resolution. 

The procedures describe the process that is taken from the point at which the suspected security flaw is 
determined to be a security flaw to the point at which it is resolved. 
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14.3.3.8 Work unit ALC_FLR.3.8 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would help to ensure that the TOE users are issued corrective actions for each security flaw. 

The procedures describe the process that is tal<en from the point at which a security flaw is resolved to the 
point at which the corrective action is provided. The procedures for delivering corrective actions should be 
consistent with the security objectives; they need not necessarily be identical to the procedures used for 
delivering the TOE, as documented to meet Delivery (ADO_DEL), if included in the assurance requirements. 
For example, if the hardware portion of a TOE were originally delivered by bonded courier, updates to 
hardware resulting from flaw remediation would likewise expected to be distributed by bonded courier. 
Updates unrelated to flaw remediation would follow the procedures set forth in the documentation meeting the 
Delivery (ADO_DEL) requirements. 

14.3.3.9 Work unit ALC_FLR.3-9 

ISO/IEC 15408-3 ALC_FLR.3.7C: The procedures for processing reported security flaws shall provide 
safeguards that any corrections to these security flaws do not introduce any new flaws. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would result in safeguards that the potential correction contains no adverse effects. 

Through analysis, testing, or a combination of the two. the developer may reduce the likelihood that adverse 
effects will be introduced when a security flaw is corrected. The evaluator assesses whether the procedures 
provide detail in how the necessary mix of analysis and testing actions is to be determined for a given 
correction. 

The evaluator also determines that, for instances where the source of the security flaw is a documentation 
problem, the procedures include the means of safeguarding against the introduction of contradictions with 
other documentation. 

14.3.3.10 Work unit ALC_FLR.3-10 

ISO/IEC 15408-3 ALC_FLR.3.8C: The flaw remediation guidance shall describe a means by which TOE users 
report to the developer any suspected security flaws in the TOE. 

The evaluator shall examine the flaw remediation guidance to determine that the application of these 
procedures would result in a means for the TOE user to provide reports of suspected security flaws or 
requests for corrections to such flaws. 

The guidance ensures that TOE users have a means by which they can communicate with the TOE developer. 
By having a means of contact with the developer, the user can report security flaws, enquire about the status 
of security flaws, or request corrections to flaws. 

14.3.3.11 Work unit ALC_FLR.3-11 

tSO/lEC 15408-3 ALC_FLR.3.9C: The flaw remediation procedures Shall include a procedure requiring timely 
responses for the automatic distribution of security flaw reports and the associated corrections to registered 
users who might be affected by the security flaw. 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would result in a timely means of providing the registered TOE users who might be affected with 
reports about, and associated corrections to, each security flaw. 

The issue of timeliness applies to the issuance of both security flaw reports and the associated corrections. 
However, these need not be issued at the same time. It is recognised that flaw reports should be generated 
and issued as soon as an interim solution is found, even if that solution is as drastic as Turn off the TOE . 
Likewise, when a more permanent (and less drastic) solution is found, it should be issued without undue delay. 
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It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users 
who might be affected by the security flaw; it is permissible that all TOE users be given such reports and 
corrections for all security flaws, provided such is done in a timely manner. 

14.3.3.1 2 Work unit ALC_FLR.3-1 2 

The evaluator shall examine the flaw remediation procedures to determine that the application of these 
procedures would result in automatic distribution of the reports and associated corrections to the registered 
TOE users who might be affected. 

Automatic distribution does not mean that human interaction with the distribution method is not permitted. In 
fact, the distribution method could consist entirely of manual procedures, perhaps through a closely monitored 
procedure with prescribed escalation upon the lack of issue of reports or corrections. 

It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users 
who might be affected by the security flaw; it is permissible that all TOE users be given such reports and 
corrections for all security flaws, provided such is done automatically. 

14.3.3.13 Work unit ALC_FLR.3-13 

ISO/IEC 15408-3 ALC_FLR.3.10C: T/je flaw remediation guidance shall describe a means by which TOE 
users may register with the developer, to be eligible to receive security flaw reports and corrections. 

The evaluator shall examine the flaw remediation guidance to determine that it describes a means of enabling 
the TOE users to register with the developer. 

Enabling the TOE users to register with the developer simply means having a way for each TOE user to 
provide the developer with a point of contact; this point of contact is to be used to provide the TOE user with 
information related to security flaws that might affect that TOE user, along with any corrections to the security 
flaw. Registering the TOE user may be accomplished as part of the standard procedures that TOE users 
undergo to identify themselves to the developer, for the purposes of registering a software licence, or for 
obtaining update and other useful information. 

There need not be one registered TOE user per installation of the TOE; it would be sufficient if there were one 
registered TOE user for an organisation. For example, a corporate TOE user might have a centralised 
acquisition office for all of its sites. In this case, the acquisition office would be a sufficient point of contact for 
all of that TOE user's sites, so that all of the TOE user's installations of the TOE have a registered point of 
contact. 

In either case, it must be possible to associate each TOE that is delivered with an organisation in order to 
ensure that there is a registered user for each TOE. For organisations that have many different addresses, 
this assures that there will be no user who is erroneously presumed to be covered by a registered TOE user. 

It should be noted that TOE users need not register; they must only be provided with a means of doing so. 
However, users who choose to register must be directly sent the information (or a notification of its availability). 

14.3.3.14 Work unit ALC_FLR.3.14 

ISO/IEC 15408-3 ALC_FLR.3.11C: The flaw remediation guidance shall identify the specific points of contact 
for all reports and enquiries about security issues involving the TOE. 

The evaluator shall examine the flaw remediation guidance to determine that it identifies specific points of 
contact for user reports and enquiries about security issues involving the TOE. 

The guidance includes a means whereby registered TOE users can interact with the developer to report 
discovered security flaws in the TOE or to make enquiries regarding discovered security flaws in the TOE. 
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Annex A 

(normative) 

General evaluation guidance 



A.1 Objectives 

The objective of this clause is to cover the basic evaluation techniques used to provide technical evidence of 
evaluation results. The use of such techniques helps in achieving objectivity, repeatability and reproducibility 
of the work performed by the evaluator. 

A. 2 Sampling 

This subclause provides general guidance on sampling. Specific and detailed information is given in those 
work units under the specific evaluator action elements where sampling has to be performed. 

Sampling is a defined procedure of an evaluator whereby some subset of a required set of evaluation 
evidence is examined and assumed to be representative for the entire set. It allows the evaluator to gain 
enough confidence in the correctness of particular evaluation evidence withaut analysing the whole evidence. 
The reason for sampling is to conserve resources while maintaining an adequate level of assurance. Sampling 
of the evidence can provide two possible outcomes: 

a) The subset reveals no errors, allowing the evaluator to have some confidence that the entire set is correct. 

b) The subset reveals errors and therefore the validity of the entire set is called into question. Even the 
resolution of all errors that were found may be insufficient to provide the evaluator the necessary 
confidence and as a result the evaluator may have to increase the size of the subset, or stop using 
sampling for this particular evidence. 

Sampling is a technique which can be used to reach a reliable conclusion if a set of evidence is relatively 
homogeneous in nature, e.g. if the evidence has been produced during a well defined process. 

ISO/IEC 15408 identifies the following evaluator action elements where sampling is explicitly acceptable: 

a) ADV_RCR.3.2E: "The evaluator shall determine the accuracy of the proofs of correspondence by 
selectively verifying the formal analysis." 

b) Independent testing (ATE_IND).*.2E: "The evaluator shall test a subset of the TSF as appropriate to 
confirm that the TOE operates as specified". 

c) ATE_IND.2.3E: "The evaluator shall execute a sample of tests in the test documentation to verify the 
developer test results." 

d) Covert channel analysis (AVA_CCA).*.3E: "The evaluator shall selectively validate the covert channel 
analysis through testing." 

e) AVA_MSU.2.2E and AVA_MSU.3.2E: "The evaluator shall repeat all configuration and installation 
procedures, and other procedures selectively, to confirm that the TOE can be configured and used 
securely using only the supplied guidance documentation." 

In addition ADV_1MP.1.1D requires that the developer provide the implemeatation representation for a subset 
of the TSF only. The sample of the subset should be selected in agreement with the evaluator. Provision of a 
sample of the implementation representation allows the evaluator to assess the presentation of the 
implementation representation itself and to sample the traceability evidence to gain assurance in the 
correspondence between the low-level design and the implementation representation. 
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In addition to the sampling that ISO/IEC 15408 accepts, this International Standard identifies the following 
actions where sampling is acceptable: 

a) Action CM capabilities (ACM_CAP).M E: "The evaluator shall confirm that the information provided meets 
all requirements for content and presentation of evidence." 

Here sampling is accepted for the content and presentation of evidence elements CM capabilities 
(ACM_CAP).*.8C and CM capabilities (ACM_CAP).*.9C for EAL3 and EAL4. 

b) Action ATE_FUN.1.1E: "The evaluator shall confirm that the information provided meets all requirements 
for content and presentation of evidence." 

Here sampling is accepted for the content and presentation of evidence element ATE_FUN.1.3C, 
ATE_FUN.1.4C, and ATE_FUN.1.5C for EAL2, EAL3. and EAL4. 

c) Action ALC_DVS.1.1E: "The evaluator shall confirm that the information provided meets all requirements 
for content and presentation of evidence." 

Here sampling is accepted for the content and presentation of evidence element ALC_DVS.1.2C for 
EAL3 and EAL4. 

Sampling in the cases identified in ISO/IEC 15408, and in cases specifically covered in evaluation 
methodology work items, is recognised as a cost-effective approach to performing evaluator actions. Sampling 
in other areas is permitted only in exceptional cases, where performance of a particular activity in its entirety 
would require effort disproportionate to the other evaluation activities, and where this would not add 
correspondingly to assurance. In such cases a rationale for the use of sampling in that area will need to be 
made. Neither the fact that the TOE is large and complex, nor that it has many security functional 
requirements, is sufficient justification, since evaluations of large, complex TOEs can be expected to require 
more effort. Rather it is intended that this exception be limited to cases such as that where the TOE 
development approach yields large quantities of material for a particular ISO/IEC 15408 requirement that 
would normally all need to be checked or examined, and where such an action would not be expected to raise 
assurance correspondingly. 

Sampling needs to be justified taking into account the possible impact on the security objectives and threats of 
the TOE. The impact depends on what might be missed as a result of sampling. Consideration also needs to 
be given to the nature of the evidence to be sampled, and the requirement not to diminish or ignore any 
security functions. 

It should be recognised that sampling of evidence directly related to the implementation of the TOE (e.g. 
developer test results) requires a different approach to sampling related to the determination of whether a 
process is being followed. In many cases the evaluator is required to determine that a process is being 
followed, and a sampling strategy is recommended. The approach here will differ from that taken when 
sampling a developer's test results. This is because the former case is concerned with ensuring that a process 
is in place, and the latter deals with determining correct implementation of the TOE. Typically, larger sample 
sizes should be analysed in cases related to the correct implementation of the TOE than would be necessary 
to ensure that a process is in place. 

The following principles should be followed whenever sampling is performed: 

a) The sample size should be commensurate with the cost effectiveness of the evaluation and will depend 
on a number of TOE dependent factors (e.g. the size and complexity of the TOE, the arnount of 
documentation), but a minimum size of 20% should be adopted as a norm for sampling material related to 
the TOE implementation. Where sampling relates to gaining evidence that a process (e.g. visitor control 
or design review) is being followed, a percentage figure is not appropriate. The evaluator should sample 
sufficient information to gain reasonable confidence that the process is being followed, and justify the 
sample size. 
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b) The sample should be representative of all aspects relevant to the areas that are sampled. In particular, a 
selection should cover a variety of components, security functions, developer and operational sites (if 
more than one is involved) and hardware platform types (if more than one is involved). 

c) The sponsor and developer should not be informed in advance of the exact composition of the sample, 
subject to ensuring timely delivery of the sample and supporting deliverable, e.g. test harnesses and 
equipment to the evaluator in accordance with the evaluation schedule. 

d) The choice of the sample should be free from bias to the degree possible (one should not always choose 
the first or last item). Ideally the sample selection should be done by someone other than the evaluator. 

Errors found in the sample can be categorised as being either systematic or sporadic. If the error is systematic, 
the problem should be corrected and a complete new sample taken. If properly explained, sporadic errors 
might be solved without the need for a new sample, although the explanation should be confirmed. The 
evaluator should use judgement in determining whether to increase the sample size or use a different sample. 

A.3 Consistency analysis 

This subclause provides general guidance on consistency analysis. Specific and detailed information is given 
in those work units under the specific evaluator action elements where a consistency analysis has to be 
performed. 

A consistency analysis is a defined procedure of an evaluator whereby a special part of an evaluation 
deliverable is itself analysed (internally consistent) or is compared with one or more other evaluation 
deliverables. 

ISO/IEC 15408 distinguishes between different kinds of consistency analysis: 

a) The-evaluator has to analyse the internal consistency of an evaluation deliverable. Examples are: 

• ADV_FSP.1 .2C: "The functional specification shall be internally consistent." 

• ADV_HLD.1 .2C: "The high-level design shall be internally consistent." 

• ADVJMP.1 .2C: "The implementation representation shall be internally consistent." 

• ADV_LLD.1 .2C: "The low-level design shall be internally consistent." 

While performing an internal consistency analysis the evaluator has to ensure that the deliverable 
provided does not include ambiguities. The evaluation deliverable should not include contradictory 
statements contained in different portions of the deliverable. For example, informal, semiformal, or formal 
presentations of the same evidence should agree with one another. 

The evaluator should consider that parts of an evaluation deliverable may exist in separate documents 
(e.g. procedures for the secure installation, generation, and start-up may exist in three different 
documents). 

b) The evaluator has to analyse that an evaluation deliverable is consistent with one or more other 
deliverables. Examples are: 

• AGD_ADM.1.7C: "The administrator guidance shall be consistent with all other documentation 
supplied for evaluation." 

• AGD_USR.1.5C: "The user guidance shall be consistent with all other documentation supplied for 
evaluation." 

This consistency analysis requires the evaluator to verify that the descriptions of functions, security 
parameters, procedures and security- relevant events described in one document are consistent with 
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those described in other documents supplied for evaluation. This means that the evaluator should 
consider possible inconsistencies with other sources of information. Examples include: 

• inconsistencies with other guidelines on the use of security functions; 

• Inconsistencies with the ST (e.g. threats, secure usage assumptions, non-IT security objectives, or IT 
security functions); 

• inconsistent use of security parameters with their description in the functional specification or low-level 
design; 

• inconsistent description of security-relevant events with respect to information presented in the high- 
level or low-levef design documents; 

• conflicts of security enforcing functions with the informal TSP model. 

c) The evaluator has to analyse both that an evaluation deliverable is internally consistent, and that an 
evaluation deliverable is consistent with other deliverables. An example is: 

• AVA_MSU.1 .2C: "The guidance documentation shall be complete, clear, consistent, and reasonable." 

Here it is required that guidance as a whole meet the requirement for consistency. Given that such 
guidance documentation may be contained in a single document, or in many separate documents, the 
requirement covers consistency across all guidance, within and between documents. 

d) The evaluator has to check an analysis provided by the developer that is required to demonstrate 
consistency. Examples are: 

• ADV__;SPM.1.3C: "The TSP model shall include a rationale that demonstrates that it is consistent and 
complete with respect to all policies of the TSP that can be modelled." 

• ADV_SPM.1.4C: "The demonstration of correspondence between the TSP model and the functional 
specification shall show that alt of the security functions in the functional specification are consistent 
and complete with respect to the TSP model." 

In these cases it is the developer who has to present the evidence for consistency. However, the 
evaluator has to understand this analysis and has to confirm it, possibly even performing an independent 
analysis if necessary. 

The consistency analysis can be performed by examination of the evaluation deliverable(s). The evaluator 
should adopt a reasonable and structured approach to analysing the consistency of documents and may 
combine it with other activities, such as mapping or traceability, that are performed as part of other work units. 
The evaluator may be able to resolve any inconsistencies found by appealing to the formal description, if any. 
Similarly, use of semi-formal notations in deliverables, whilst not as precise as formal notation, can be used to 
reduce ambiguity in the deliverables. 

Ambiguity can arise explicitly from, for example, conflicting statements or implicitly when statements are not 
sufficiently precise, it should be noted that verbosity is not, in itself, sufficient grounds to assume a fait verdict 
against the consistency criteria. 

The consistency check of deliverables may highlight omissions that may require a rework of already 
performed work units. For example, the consistency check of the security objectives may identify an omission 
of one or more security requirements. In this case the evaluator should check the correspondence between 
the security objectives and the TSF. 
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A.4 Dependencies 

In general it is possible to perform the required evaluation activities, sub-activities, and actions in any order or 
in parallel. However, there are different kinds of dependencies which have to be considered by the evaluator. 
This subclause provides general guidance on dependencies between different activities, sub-activities, and 
actions. 

A.4.1 Dependencies between activities 

For some cases the different assurance classes may recommend or even require a sequence for the related 
activities. A specific instance is the ST activity. The ST evaluation activity is started prior to any TOE 
evaluation activities since the ST provides the basis and context to perform them. However, a final verdict on 
thre ST evaluation may not be possible until the TOE evaluation is complete, since changes to the ST may 
result from activity findings during the TQE evaluation. 

A.4.2 Dependencies between sub-activities 

Dependencies identified between components in ISO/IEC 15408-3 have to be considered by the evaluator. An 
example for this kind of dependency is AVA_VLA.1 Developer vulnerability analysis. This component claims 
dependencies on ADV_FSP.1 Informal functional specification, ADV_HLD.1 Descriptive high-level design, 
AGD_ADM.1 Administrator guidance and AGD_USR.1 User guidance. 

A sub-activity can be assigned a pass verdict normally only if all those sub-activities are successfully 
completed on which it has a dependency. For example, a pass verdict on AVA_VLA.1 Developer vulnerability 
analysis can normally only be assigned if the sub-activities related to ADVFSP.I Informal functional 
specification, ADV_HLD.1 Descriptive high-level design, AGD_ADM.1 Administrator guidance and 
AGD_USR.1 User guidance are assigned a pass verdict too. 

So when determining whether a sub-activity will impact another sub-activity, the evaluator should consider 
whether this activity depends on potential evaluation results from any dependent sub-activities. Indeed, it may 
be the case that a dependent sub-activity will impact this sub-activity, requiring previously completed evaluator 
actions to be performed again. 

A significant dependency effect occurs in the case of evaluator-detected flaws. If a flaw is identified as a result 
of conducting one sub-activity, the assignment of a pass verdict to a dependent sub-activity may not be 
possible until all flaws related to the sub-activity upon which it depends are re^solved. 

Note that some components from ISO/IEC 15408, such as ASEJNT and ASE_DES have a dependency on 
each other, and that therefore this problem occurs for every sequence of performing the related sub-activities. 

A.4.3 Dependencies between actions 

tt may be the case, that results which are generated by the evaluator during one action are used for 
performing another action. For example, actions for completeness and consistency cannot be completed until 
the checks for content and presentation have been completed. This means for example that the evaluator is 
recommended to evaluate the PP/ST rationale after evaluating the constituent parts of the PP/ST. 

A.5 Site Visits 

This subclause provides genera! guidance on site visits. Specific and detailed information is given in work 
units for those activities where site visits are performed: 

a) CM automation (ACM_AUT); 

b) CM capabilities (ACM_CAP).n (with n>2): 

c) Delivery (ADO„DEL); 

d) Development security {ALC_DVS). 
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A development site visit is a useful means whereby the evaluator determines whether procedures are being 
followed in a manner consistent with that described in the documentation. 

Reasons for visiting sites include: 

a) to observe the use of the CM system as described in the CM plan; 

b) to observe the practical application of delivery procedures; 

c) to observe the application of security measures during development. 

During an evaluation it is often necessary that the evaluator will meet the developer more than once and It is a 
question of good planning to combine the site visit with another meeting to reduce costs. For example one 
might combine the site visits for configuration management, for the developer's security and for delivery. It 
may also be necessary to perform more than one site visit to the same site to allow the checking of all 
development phases. It should be considered that development could occur at multiple facilities within a single 
building, multiple buildings at the same site, or at multiple sites. 

The first site visit should be scheduled early during the evaluation. In the case of an evaluation which starts 
during the development phase of the TOE, this will allow corrective actions to be taken, if necessary. In the 
case of an evaluation which starts after the development of the TOE, an early site visit could allow corrective 
measures to be put in place if serious deficiencies in the applied procedures emerge. This avoids 
unnecessary evaluation effort, 

Interviews are also a useful means of determining whether the written procedures reflect what is done. In 
conducting such interviews, the evaluator should aim to gain a deeper understanding of the analysed 
procedures at the development site, how they are used in practice and whether they are being applied as 
described in the provided evaluation evidence. Such interviews complement but do not replace the 
examination of evaluation evidence. 

To prepare for the site visit a checklist, based on the evaluation evidence provided should be generated by the 
evaluator. The results of the site visit should be recorded. 

Site visits may not be deemed necessary if e.g. the development site has recently been visited for another 
TOE evaluation or particular ISO 9000 procedures were confirmed as being followed. Other approaches to 
gain confidence Should be considered that provide an equivalent level of assurance (e.g. to analyse 
evaluation evidence). Any decision not to make a visit should be determined in consultation with the overseer. 

A.6 TOE Boundary 

The identity of what is evaluated will appear in the ETR, on the certificate, in the ST, and on the list of 
evaluated products. Although products are typically bought and sold, evaluations are concerned with TOEs. 
The following were agreed as the basis of definitions used In this International Standard, along with their 
interrelationships and effects upon evaluations and certification. 

A.6.1 Product and system 

The product is the collection of hardware and/or software that is available for use. Some purveyors might 
bundle a collection of products (e.g. a wordprocessor, spreadsheet, and graphics application) into yet another 
product (e.g. an office automation system). But, provided that it is available for use. either by the public, by 
other manufacturers, or by limited customers, the resulting collection is considered to be a product. 

A system consists of one or more products in a known operational environment. The main difference between 
a product evaluation and a system evaluation is that, for a system evaluation, the evaluator takes into account 
the actual environment instead of theorising a hypothetical one, as done for a product evaluation. 
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A.6.2 TOE 

The TOE is the entity that is evaluated as defined by the ST. While there are cases where a TOE makes up 
the entire product, this need not be the case. The TOE may be a product, a part of a product, a set of products, 
a unique technology never to be made into a product, or combinations of all of these, in a specific 
configuration or set of configurations. This specific configuration or set of configurations is called the evaluated 
configuration. The ST clearly describes the relation between the TOE and any associated products. 

This evaluated configuration is identified in sufficient detail to differentiate hardware included in the evaluated 
configuration from hardware that is not included in the evaluated configuration, though it might be available as 
part of the product upon which the TOE is based. This identification makes it apparent to potential customers 
what product must be purchased, and what configuration options must be used, in order for the TOE to run 
securely. 

A.6.3 TSF 

The TSF is the collection of those functions within the TOE that enforce the security of the TOE as defined by 
the ST. There may be functions within the TOE that contribute nothing to the security of the TOE as defined 
by the ST; consequently, such functions would not be part of the TSF. 

The hardware portions of the TSF are described at a level of detail commensurate with the assurance 
requirements related to the relevant development documentation (functional specification, high-level design, 
low-level design) and the testing documentation. The level of hardware identification is determined by the 
impact that the hardware features have upon the security functions and assurances being claimed. 

A.6.4 Evaluation 

An implicit assumption for all evaluations is that the TOE is (by definition) the product or system in its 
evaluated configuration; this assumption need not be explicitly included in the list of assumptions for the 
evaluation. The TOE undergoes the scrutiny of the evaluation: analysis is performed only within 1he evaluated 
configuration, testing is performed upon this evaluated configuration, exploitable vulnerabilities are identified in 
this evaluated configuration, and assumptions are relevant only in the evaluated configuration. The ease with 
which the TOE can exit this configuration is important, and must be considered where Misuse (AVA_MSU) is 
called up. This will look at the robustness of the TOE configuration, and the impact of any accidental or 
intentional deviations from it that may occur without detection. 

The following example provides three TOEs, all of which are based upon the same virtual private networking 
(VPN) firewall product, but which yield different evaluation results because of the differences in the STs. 

1) A VPN-fjrewall which is configured in such a way that the VPN functionality is turned off. All threats 
in the ST are concerned with access to the safe network from the unsafe network. 

The TOE is the VPN-firewall configured in such a way that the VPN functionality is turned off. If the 
administrator were to configure the firewall such that some or all VPN functions were enabled, the product 
would not be in an evaluated configuration; it would therefore be considered to be unevaluated, and so 
nothing could be stated about its security. 

2) A VPN-firewall, where all threats In the ST are concerned with access to the safe network from the 
unsafe network. 

The TOE is the entire VPN-firewall. The VPN functions are part of the TOE, so one of the things to be 
determined during the evaluation would be whether there are means to gain access to the safe network from 
the unsafe network through the VPN functions. 

3) A VPN-firewall, where all threats In the ST are concerned with either access to the safe network 
from the unsafe network or confidentiality of traffic on the unsafe network. 
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The TOE is the entire VPN-firewali. The VPN functions are part of the TOE, so one of the things to be 
determined during the evaluation would be whether the VPN functions permit the realisation of any of the 
threats described in the ST. 

A.6.5 Certification 

From the earlier paragraphs, it is clear that evaluating the same product with different STs leads to different 
TOEs with different TSFs. Consequently, the Certificates, ETR, the STs, and the entries in the Evaluated 
Products List will have to differ among the evaluations to be of any use to potential customers. 

Note that, for the above example of three different firewall evaluations, the apparent differences between 
these Certificates would be subtle, as the three VPN-firewalls would all lead to certificates identifying the TOE 
as: 

The XYZ Firewall product, as described in the Evaluated Configuration identified in Security Target #ABC. 

with a different identifier for each ST ABC. 

Therefore, the evatuator has to ensure that the ST adequately describes the TOE in terms S3f what 
functionality is within the scope of the evaluation. A clear explanation is vital because prospective customers 
of evaluated products will consult the STs of the products that they are considering to buy in order to 
determine which security functionality of those products have been evaluated. 

A.7 Threats and FPT Requirements 

The PP/ST author identifies threats (and from a threat perspective, there is no distinction made between the 
threat of a malicious user and that from an incorrect implementation exploitable through the external interface 
of the TSF) and uses these to determine the inclusion or exclusion of TSF physical protection (FPT_PHP), 
Domain separation (FPT_SEP), and/or Reference mediation (FPT_RVM) in the PP/ST. That is, all of these 
requirement families presuppose a threat to the TOE of physical tampering, user interference, or bypass: 

a) The requirement for TSF protection is directly related to the statement of environment for the TOE. Where 
the threat of tampering or bypass is cited, either explicitly or implicitly, measures must be provided, either 
by the TOE or its environment, to address the threat. 

b) The threat of tampering or bypass is typically indicated by the presence in the TOE environment of 
untrusted subjects (commonly human users), and where motivation exists to attack the assets that the 
TOE is intended to protect. 

c) When assessing the statement of security requirements in the PP/ST, the evaiuator determines the need 
for TSF protection to meet the security objectives, and where this need is established checks for the 
presence of functional requirements to meet it. Where the need for protection is identified, and no such 
protection is provided by the TOE or its environment, then a fail verdict will be assigned to the PP/ST 
evaluation sub-activity APE/ASE_REQ. 

There must be some form of protection for the TOE if it is to be able to enforce its security policy. After all, if 
the TSF is not protected from corruption, there is no guarantee that its policy enforcement functions will 
perform as expected. 

This protection can be provided in several ways. In an operating system, in which there are multiple users who 
have a rich (programming) interface to the TOE, the TSF must be able to protect itself. However, if the TOE is 
such that it has a limited interface, or a restricted usage, the necessary protection may be provided through 
means outside the TOE. 

it is the PP/ST author's responsibility to choose a combination of TOE security functions, assumptions about 
the IT environment, and other assumptions that provides for the needed self protection of the TOE security 
functions. It is the evaluator's responsibility to confirm that the necessary protection is provided. Depending on 
the TOE and the assumptions, the needed protection may demand functional security requirements from the 
FPT class; but there are circumstances under which it may not. 
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A.7.1 TOEs not necessarily requiring the FPT class 

It is conceivable that some TOEs (such as an embedded TOE with no user interface) would not be subject to 
these threats. A PP/ST for a TOE providing a rich user interface that includes these threats yet has no TSF 
physical protection (FPT_PHP), Reference mediation (FPT_RVM), and Domain separation (FPT_SEP) 
requirements is most likely an invalid PP/ST. The TOEs that may not need to include the FPT: ProtecSon of 
the TSF self-protection requirements may be divided into three types: 

A.7.1.1 TOEs with a Limited User Interface 

A TOE that provides only a limited interface to the (untrusted) user already, by virtue of its limited interface, 
may provide sufficient constraints on the user's actions that even a malicious user may not be able to corrupt 
the TOE. For example, a device like a calculator, or a user authentication token, may have only a few possible 
input keys. The untrusted user interface to a communications device such as a router or guard is even more 
restricted: users can communicate only indirectly, typically through protocol data units or messages. 

A. 7. 1.2 TOE enforcing no relevant Security Policies 

A TOE enforcing no access control or information flow control policies would presumably have no concern 
about a user accessing data of another user or of the TSF. In such a case, there wouki be little need for the 
separation of users that Domain separation (FPT_SEP) implies. Similarly, if there are no perceived assets 
{such as IT resources) in need of protection (such as against denial of service), there may not be a need for 
FPT requirements. 

A. 7. 1.3 Protection is provided by the Environment 

Protection of the TSF is often to be provided by the TOE environment, rather than the TOE itself (e.g. as in the 
case of an application running on a trusted operating system, where the application is the TOE). In such cases 
the evaluation will consider whether the environmental mechanisms provide the required protection. The 
protection measures themselves are assumed to operate correctly, but the manner in which they are applied 
to protect the TOE can influence the scope of the evaluation. 

For example, the privilege assigned by an operating system to object files within an application will determine 
the application's potential for violating the underlying operating system's TSP. It is possible to conceive of two 
implementations of the same application that make differing use of operating system protection measures, 
such that significantly different TSFs would be implied. Thus, even where the protection mechanisms are 
implemented by the TOE environment it remains necessary to examine the use made of those mechanisms 
before a determination of the TSF can be made. 

A.7.2 Impact upon Assurance Fanriiies 

The inclusion/exclusion of the FPT self-protection requirements from the PPISJ will affect the following 
requirements: 

A.7.2.1 ADV 

Where the threat of tampering or bypass does not exist, the evaluation will focus on correct operation of the 
TSF. This will include consideration of all functions within the TOE that contribute directly or indirectly to the 
enforcement of the TSP. Functions that fall into neither of these categories need not be examined (the 
presence of errors in the implementation of these functions that can interfere with the correct operation of the 
TSF will be established through testing of the TSF). 

Where self-protection functions have been claimed, the description of their implementation will identify the 
protection mechanisms, from which a determination of the TSF boundaries can be made. Identification of the 
TSF boundaries and interfaces, together with a determination of the efficacy of the TSF protection 
mechanisms claimed, will allow the evaluation to be limited in scope. This limitation will exclude functions 
outside the TSF, since these cannot interfere with correct TSF operation. In many cases, the TSF boundary 
will include some functions that do not conthbute to the enforcement of the TSP, and these functions will need 
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to be examined during the evaluation. Those functions that can be determined not to fall within the TSF need 
not be examined by the evaluator. 

A.7.2.2 AVA_VLA 

Vulnerability analysis in ISO/IEC 15408 determines the impact of vulnerabilities on the operation of the TOE in 
its intended environment. If no threat of tampering or bypass is identified in the ST, then the search for 
vulnerabilities by the developer and evaluator, where required, should exclude consideration of such attacks. 

A.7.2.3 ATEJND 

The application notes for fndependent testing (ATEJND) call for testing of obvious public domain weaknesses 
that may be applicable to the TOE. Such weaknesses that are based on the intent to tamper or bypass the 
TOE need only be considered where such a threat has been identified. 

A.8 Strength of function and vulnerability analysis 

A comparison shows that there are important differences and important similarities between a strength of TOE 
security function analysis and a vulnerability analysis. 

An important similarity is based in their use of attack potential. For both analyses, the evaluator determines 
the minimum attack potential required by an attacker to effect an attack, and arrives at some conclusion about 
1he TOE'S resistance to attacks. Table A.1 and Table A.2 demonstrate and further describe the relationship 
between these analyses and attack potential. 



vulnerability 
component 


TOE resistant to 
attacker with 
attack potential 
of. 


Remaining vulnerabilities only exploitable by 
attacker with attack potential of: 


VLA.4 


high 


Not applicable - successful attack beyond practicality 


VLA.3 


moderate 


high 


VLA.2 


low 


moderate 



Table A.1 Vulnerability analysis and attack potential 
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insufficient protection against attacker with attack 
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SOP - high 


high 


Not applicable - successful attack beyond practicality 


SOF- 


moderate 


high 


medium 






SOP - basic 


low 


moderate 



Table A.2 Strength of TOE security function and attack potential 

Important differences between these analyses are based in the nature of the TOE security function as well as 
in the nature of the attack. Strength of TOE security function analysis is only performed on probabilistic or 
permutational functions, except those which are based on cryptography. Furthermore, the analysis assumes 
that the probabilistic or permutational security function is implemented flawlessly and that the security function 
is used during attack within the limits of its design and implementation. As shown in Table A.2, a SOP rating 
then reflects the attack, described in terms of attack potential, against which the probabilistic or permutational 
security function is designed to protect. 

A vulnerability analysis applies to all non-cryptographic TOE security functions, including ones that are 
probabilistic or permutational in nature. Unlike a SOP analysis, no assumptions are made regarding the 
correctness of the security function's design and implementation; nor are constraints placed on the attack 
method or the attacker's interaction with the TOE - if an attack is possible, then it is to be considered during 
the vulnerability analysis. As shown in Table A.1, successful evaluation against a vulnerability assurance 
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component reflects the level of threat, described in terms of attack potential, against which all TOE security 
functions are designed and implemented to protect. 

Common use of the notion of attack potential creates a link between SOF claims and vulnerability 
assessments, but this link should not be seen as creating a mandatory binding between the level of SOF claim 
and the assurance component selected from Vulnerability analysis {AVA_VIJ\). for example, the choice of 
AVA_VLA.2 Independent vulnerability analysis, which requires resistance to attackers with a low attack 
potential, does not restrict the choice of SOF rating to SOF-basic. Given that a vulnerability is inherently 
present in any probabilistic or permutational function, and that such functions are usually prominent aspects of 
a public interface (e.g. a password), a PP/ST author may require a higher level of resistance to attack at these 
points, and may select a higher SOF rating. A minimum claim of SOF-basic is required wherever components 
for Strength of TOE security functions (AVA_SOF) are claimed. The Vulnerability analysis (AVA_VLA) 
component claimed imposes a floor on the SOF claim, and a SOF claim of SOF-basic should be seen as 
inconsistent with selection of AVA_VLA.3 Moderately resistant. 

A.8.1 Attack potential 

A.8.1 .1 Application of attack potential 

Attack potential is a function of expertise, resources and motivation; each of these factors will be discussed.. 
Attack potential is especially considered by the evaluator in two distinct ways during the ST evaluation and the 
vulnerability assessment activities. During the ST evaluation, the evaluator determines whether or not the 
choice of the assurance requirement components, in particular the components of the AVA: Vulnerability 
assessment class, are commensurate with the threat attack potential (see ASE_REQ.1.4C). Cases where the 
assurance is not commensurate may mean either that the evaluation will not provide sufficient assurance, or 
that the evaluation will be unnecessarily onerous. During the vulnerability assessment the evaluator is using 
attack potential as a means of determining the exploitability of identified vulnerabilities in the in^-^nded 
environment. 

A.8.1 .2 Treatment of motivation 

Motivation is an attack potential factor that can be used to describe several aspects related to the attacker and 
the assets the attacker desires. Firstly, motivation can imply the likelihood of an attack - one can Infer from a 
threat described as highly motivated that an attack is imminent, or that no attack is anticipated from an un- 
motivated threat. However, except Tor the two extreme levels of motivation, it is difficult to derive a probability 
of an attack occurring from motivation. 

Secondly, motivation can imply the value of the asset, monetarily or othenwise, to the either the attacker or the 
asset holder. An asset of very high value is more likely to motivate an attack compared to an asset of little 
value. However, other than in a very general way, it is difficult to relate asset value to motivation because the 
value of an asset is subjective - it depends largely upon the value an asset holder places on it. 

Thirdly, motivation can imply the expertise and resources with which an attacker is willing to effect an attack. 
One can infer that a highly motivated attacker is likely to acquire sufficient expertise and resources to defeat 
the measures protecting an asset. Conversely, one can infer that an attacker with significant expertise and 
resources is not willing to effect an attack using them if the attacker's motivation is low. 

During the course of preparing for and conducting an evaluation, all three aspects of motivation are at some 
point considered. The first aspect, likelihood of attack, is what may inspire a developer to pursue an evaluation. 
If the developer believes that the attackers are sufficiently motivated to mount an attack, then an evaluation 
can provide assurance of the ability of the TOE to thwart the attacker's efforts. Where the intended 
environment is welt defined, for example in a system evaluation, the level of motivation for an attack may be 
known, and will influence the selection of countermeasures. 

Considering the second aspect, an asset holder may believe that the value of the assets (however measured) 
is sufficient to motivate attack against them. Once an evaluation is deemed necessary, the attacker's 
motivation is considered to determine the methods of attack that may be attempted, as well as the expertise 
and resources used in those attacks. Once examined, the developer is able to choose the appropriate 
assurance level, in particular the AVA requirement components, commensurate with the attack potential for 
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the threats. During the course of the evaluation, and in particular as a result of completing the vulnerability 
assessment activity, the evaluator determines whetlrer or not the TOE, operating in its intended environment, 
is sufficient to thwart attackers with the identified expertise and resources. 

A.8.2 Calculating attack potential 

This subclause examines the factors that determine attack potential, and provides some guidelines to help 
remove some of the subjectivity from this aspect of the evaluation process. This approach should be adopted 
unless the evaluator determines that it is inappropriate, in which case a rationale is required to justify the 
validity of the alternative approach. 

A.8.2. 1 Identtflcation and exploitation 

For an attacker to exploit a vulnerability the vulnerability must first be identified, and then exploited. This may 
appear to be a trivial separation, but is an important one. To illustrate this, consider first a vulnerability that is 
uncovered following months of analysis by an expert, and a simple attack method published on the Internet. 
Compare this with a vulnerability that is well known, but requires enormous time and resource to exploit. 
Clearly factors such as time need to be treated differently in these cases. 

For SOF analysis, the issue of exploitation will normally be the most important, since vulnerabilities in 
probabilistic or permutational mechanisms will often be self evident. Note, however, that this may not always 
be the case. With cryptographic mechanisms, for example, knowledge of subtle vulnerabilities may 
considerably affect the effectiveness of a brute force attack. Knowledge that users of a system tend to choose 
first names as passwords will have a similar effect For vulnerability assessments above AVA_VLA.1 
Developer vulnerability analysis, the initial identification of vulnerabilities will become a much more important 
consideration, since the existence of difficult to uncover vulnerabilities may be promulgated, often rendering 
exploitation trivial. 

A.8.2.2 Factors to be considered 

The following factors should be considered during analysis of the attack potential required to exploit a 
vulnerability: 

a) Identification: 

1) Time taken to identify; 

2) Specialist technical expertise; 

3) Knowledge of the TOE design and operation; 

4) Access to the TOE; 

5) IT hardware/software or other equipment required for analysis. 

b) Exploitation: 

1 ) Time taken to exploit; 

2) Specialist technical expertise; 

3) Knowledge of the TOE design and operation; 

4) Access to the TOE; 

5) IT hardware/software or other equipment required for exploitation. 
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In many cases these factors are not independent, but may be substituted for each other in varying degrees. 
For example, expertise or hardware/software may be a substitute for time. A discussion of these factors 
follows. 

Time is the time taken by an attacker to identify or exploit an attack on a continuous basis. For the purposes of 
this discussion within minutes means an attack can be identified or exploited in less than half an hour, within 
hours means an attack can succeed in less than a day; within days means an attack can succeed In less than 
a month, and in months means a successful attack requires at least a month. 

Specialist expertise refers to the level of generic knowledge of the application area or product type (e.g. Unix 
operation systems, Internet protocols). Identified levels are as follows: 

a) Experts are familiar with the underlying algorithms, protocols, hardware, structures, etc. implemented in 
the product or system type and the principles and concepts of security employed; 

b) Proficient persons are knowledgeable in that they are familiar with the security behaviour of the product or 
system type; 

c) Laymen are unknowledgeable compared to experts or proficient persons, with no particular expertise. 

Knowledge of the TOE refers to specific expertise in relation to the TOE. This is distinct from generic expertise, 
but not unrelated to it. Identified levels are as follows: 

na) No information about the TOE, other than its general purpose; 

b) Public information concerning the TOE (e.g. as gained from user guides); 

c) Sensitive information about the TOE (e.g. knowledge of internal design). 

Care should be taken here to distinguish information required to identify the vulnerability from the information 
required to exploit it, especially in the area of sensitive information. To require sensitive information for 
exploitafion would be unusual. 

Access to the TOE is also an important consideration, and has a relationship to the fime factor. Identificafion 
or exploitation of a vulnerability may require considerable amounts of access to a TOE that may increase the 
likelihood of detection. Some attacks may require considerable effort off-line, and only brief access to the TOE 
to exploit. Access may also need to be continuous, or over a number of sessions. For the purposes of this 
discussion within minutes means that access is required for less than half an hour; within hours means access 
is required for less than a day; within days means access is required for less than a month, and in months 
means access is required for at least a month. Where access to the TOE does not increase the likelihood of 
detection (e.g. a smartcard in the attacker's possession), this factor should be ignored. 

IT hardware/software or other equipment refers to the equipment is required to identify or exploit a 
vulnerability. 

a) Standard equipment is equipment that is readily available to the attacker, either for the identification of a 
vulnerability or for an attack. This equipment may be a part of the TOE itself (e.g. a debugger In an 
operating system), or can be readily obtained (e.g. Internet downloads, or simple attack scripts). 

b) Specialised equipment is not readily available to the attacker, but could be acquired without undue effort. 
This could include purchase of moderate amounts of equipment (e.g. protocol analyser), or development 
of more extensive attack scripts or programs. 

Tc) Bespoke equipment is not readily available to the public as it may need to be specially produced (e.g. 
very sophisticated software), or because the equipment is so specialised that its distribution is controlled, 
possibly even restricted. Alternatively, the equipment may be very expensive. Use of hundreds of PCs 
linked across the Internet would fall into this category. 
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Specialist expertise and knowledge of the TOE are concerned with the information required for persons to be 
able to attack a TOE. There is an implicit relationship between an attacker's expertise and the ability to 
effectively make use of equipment in an attack. The weaker the attacker's expertise, the lower the potential to 
use equipment. Likewise, the greater the expertise, the greater the potential for equipment to be used in the 
attack. Although implicit, this relationship between expertise and the use of equipment does not always apply, 
for instance, when environmental measures prevent an expert attacker's use of equipment, or when, through 
the efforts of others, attack tools requiring little expertise to effectively use are created and freely distributed 
(e.g. via the Internet). 

A.8.2.3 An approach to calculation 

The above subclause identifies the factors to be considered. However, further guidance is required if 
evaluations are to be conducted on a standard basis. The following approach is provided to assist in this 
process. The numbers have been provided with the objective of achieving ratings that are consistent with the 
relevant evaluation levels. 

Table A.3 identifies the factors discussed in the previous subclause and associates numeric values with the 
two aspects of identifying and exploiting a vulnerability. When determining the attack potential for a given 
vulnerability, one value should be selected from each column for each factor (giving 10 values). When 
selecting values the intended environment for the TOE should be assumed. The 10 values are summed, 
giving a single value. This value is then checked using Table A.4 to determine the rating. 

Where a fector falls close to the boundary of a range the evaluator should consider use of an intermediate 
value to those in the table. For example, if access to the TOE is required for 1 hour in order to exploit the 
vulnerability, or if access is detectable very rapidly, then a value between and 4 may be selected for that 
factor. The table is ir^tended as a guide. 



Factor 


Range 


Identifying 
value 


Exploiting 
value 


Elapsed Time 


< 0.5 hour 








< 1 day 


2 


3 


< 1 month 


3 


5 


> 1 month 


5 


8 


Not practical 


* 


* 


Expertise 


Layman 








Proficient 


2 


2 


Expert 


5 


4 


Knowledge of 
TOE 


None 








Public 


2 


2 


Sensitive 


5 


4 


Access to TOE 


< 0.5 hour, or access 
uadetectable 








< 1 day 


2 


4 


< 1 month 


3 


6 


> 1 month 


4 


9 


Not practical 


* 


* 


Equipment 


None 








Standard 


1 


2 


Specialised 


3 


4 


Bespoke 


5 


6 



Table A.3 Calculation of attack potential 

* Indicates that the attack path is not exploitable within a timescaie that would be useful to an attacker. Any 
value of * indicates a High rating. 

For a given vulnerability it may be necessary to make several passes through the table for different attack 
scenarios (e.g. trading off expertise for time or equipment). The lowest value obtained for these passes should 
be retained. 
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In the case of a vulnerability that has been identified and is in the public domain, the identifying values should 
be selected for an attacker to uncover that vulnerability in the public domain, rather than to initially identify it. 

Table A.4 should then be used to obtain a rating for the vulnerability. 



Range of values 


Resistant to attacker with attack potential of: | SOF rating 


<10 


No rating 


10-17 


Lov\/ 


Basic 


18-24 


Moderate 


Medium 


>24 


High 


High 



Table A.4 Rating of vulnerabilities 

An approach such as this cannot take account of every circumstance or factor, but should give a better 
indication of the level of resistance to attack required to achieve the standard ratings. Other factors, such as 
the reliance on unlikely chance occurrences, or the likelihood of detection before an attack can be completed, 
are not included in the basic model, but can be used by an evaluator as justification for a rating other than 
tbose that the basic model might indicate. 

In cases where, for example, a password mechanism is being rated, and the TOE implementation is such that 
only a very few attempts are permitted before the attack is curtailed, the strength rating becomes related 
almost entirely to the probability of a correct guess during those few attempts. Such curtailment measures 
would be viewed as part of the access control function, and whereas the password mechanism itself may 
receive, for example, only a SOF-medium rating, the access control function may be judged to be SOF-high. 

It should be noted that whereas a number of vulnerabilities rated individually may indicate a high resistance to 
attack, the presence of other vulnerabilities may alter the table values, such that the combination of 
vulnerabilities indicates that a lower overall rating is applicable. In other words, the presence of one 
vulnerability may make another one easier to exploit. Such an assessment should form part of the developer 
and evaluator vulnerability analysis. 

A.8.3 Example strength of function analysis 

The SOF analysis for a hypothetical pass number mechanism is provided below. 

Information gleaned from the ST and design evidence reveals that identification and authentication provides 
the basis upon which to control access to network resources from widely distributed terminals. Physical 
access to the terminals is not controlled by any effective means. The duration of access to a terminal is not 
controlled by any effective means. Authorised users of the system choose their own pass numbers when 
initially authorized to use the system, and thereafter upon user request. The system places the following 
restrictions on the pass numbers selected by the user: 

a) the pass number must be at least four and no greater than six digits long; 

b) consecutive numerical sequences are disallowed (such as 7,6,5,4,3); 

c) repeating digits is disallowed (each digit must be unique). 

Guidance provided to the users at the time of pass number selection is that pass numbers should be as 
random as possible and should not be affiliated with the user in some way - a date of birth, for instance. 

The pass number space is calculated as follows: 

a) Patterns of human usage are an important considerations that can influence the approach to searching a 
password space, and thus affect SOF. Assuming the worst case scenario and the user chooses a number 
comprising only four digits, the number of pass number permutations assuming that each digit must be 
unique is: 

7{8)(0)(1()) --.^jO-l(l 
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b) The number of possible increasing sequences is seven, as is the number of decreasing sequences. The 
pass number space after disallowing sequences is: 

5040 - 14 = r,02G 

Based on further information gleaned from the design evidence, the pass number mechanism is designed with 
a terminal locking feature. Upon the sixth failed authentication attempt the terminal is locked for one hour. The 
failed authentication count is reset after five minutes so that an attacker can at best attempt five pass number 
entries every five minutes, or 60 pass number entries every hour. 

On average, an attacker would have to enter 2513 pass numbers, over 2513 minutes, before entering the 
correct pass number. The average successful attack would, as a result, occur in slightly less than: 

■ — ^ i'lhtnirfi 

I) our 

Using the approach described in the previous subclause the identifying values would be the minimum from 
each category (total 0), since the existence of the vulnerability in such a function is clear. For exploitation, 
based on the above calculations, it is possible that a layman can defeat the mechanism within days {given 
access to the TOE), without the use of any equipment, and with no knowledge of the TOE, giving a value of 
11. Given the resulting sum, 11, the attack potential required to effect a successful attack is determined to be 
at least moderate. 

The SOF ratings are defined in terms of attack potential in ISO/IEC 15408-1, Subclause 2. Since a 
mechanism must be resistant to an attacker with tow attack potential to claim SOF-basic, and since the pass 
number mechanism is resistant to an attacker with low attack potential, then this pass number mechanism 
rates, at best, SOF-hasic. 

A. 9 Scheme Responsibilities 

This International Standard describes the minimum technical work that evaluations conducted under oversight 
(scheme) bodies must perform. However, it also recognises (both explicitly and implicitly) that there are 
activities or methods upon which mutual recognition of evaluation results do not rely. For the purposes of 
thoroughness and clarity, and to better delineate where this International Standard ends and an individual 
scheme's methodology begins, the following matters are left up to the discretion of the schemes. Schemes 
may choose to provide the following, although they may choose to leave some unspecifred. (Every effort has 
been made to ensure this list is complete; evaluators encountering a subject neither listed here nor addressed 
in this International Standard should consult with their evaluation schemes to determine under whose 
auspices the subject falls.) 

The matters that schemes may choose to specify include: 

a) what is required in ensuring that an evaluation was done sufficiently - every scheme has a means of 
verifying the work of its evaluators, whether by requiring the evaluators to present their findings to the 
oversight body, by requiring the oversight body to redo the evaluator's work, or by some other means that 
assures the scheme that all evaluation bodies are adequate and comparable; 

b) process for disposing of evaluation evidence upon completion of an evaluation; 

c) any requirements for confidentiality (on the part of the evaluator and the non-disclosure of information 
obtained during evaluation); 



275 



IS 15671 :2006 
ISO/IEC 18045 : 2005 

d) the course of action to be taken if a problem is encountered during the evaluation (whether the evaluation 
continues once the probtem is remedied, or the evaluation ends immediately and the remedied product 
must be re-submitted for evaluation); 

e) any specific (natural) language in which documentation must be provided; 

f) any recorded evidence that must be submitted in the ETR - this International Standard specifies the 
minimum to be reported in an ETR; however, individual schemes may require additional information to be 
included; 

g) any additional reports (other than the ETR) required from the evaluators -for example, testing reports; 

h) any specific ORs that may be required by the scheme, including the structure, recipients, etc. of any such 
ORs; 

i) any specific content structure of any written report as a result from an ST evaluation - a scheme may 
have a specific format for all of its reports detailing results of an evaluation, be it the evaluation of a TOE 
or of an ST; 

j) any additional PP/ST identification information required; 

k) any activities to determine the suitability of explicitly-stated requirements in an ST; 

I) any requirements for provision of evaluator evidence to support re-evaluation and re-use of evidence; 

m) any specific handling of scheme identifiers, logos, trademarks, etc.; 

n) any specific guidance in dealing with cryptography; 

0) handling and application of scheme, national and international interpretations; 

p) a list or characterisations of suitable alternative approaches to testing where testing is infeasible; 

q) the mechanism by which an overseer can determine what steps an evaluator took while testing; 

r) preferred test approach (if any): at internal interface or at external interface; 

s) a list or characterisation of acceptable means of conducting the evaluator's vulnerability analysis (e.g. 
flaw hypothesis methodology); 

t) information regarding any vulnerabilities and weaknesses to be considered; 
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